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ABSTRACT 


Recent  studies  suggest  that  China  is  developing  a  new  class  of  ballistic  missiles 
that  can  be  used  against  moving  targets,  such  as  ships.  One  such  technology  is  anticipated 
to  cover  a  range  of  2,000  kilometers  and  operate  at  a  speed  of  Mach  10.  The  threat  is  also 
capable  of  maneuvering  both  during  the  midcourse  and  terminal  flight  phases  for  the 
purposes  of  guidance,  target  acquisition,  and  countermeasures.  This  threat  could  greatly 
impact  the  current  concept  of  operations  of  U.S.  Navy  ships  and  alter  national  defense 
policies.  While  current  ballistic  missile  defense  solutions  are  capable  of  intercepting 
threats  in  midcourse  and  terminal  flight  phases,  no  comprehensive  system  has  been 
developed  to  counter  a  ballistic  missile  threat  that  can  (1)  maneuver  upon  reentry  in  the 
endoatmosphere  and  (2)  be  used  to  attack  a  moving  defended  area,  such  as  a  U.S.  Navy 
carrier  strike  group  (CSG).  To  fulfill  this  need,  the  Anti-Ship  Ballistic  Missile  Defense 
(ASBMD)  team  conducted  research  and  developed  a  notional  architecture  for  a  system  of 
systems  solution  that  could  be  integrated  into  the  existing  Ballistic  Missile  Defense 
System  (BMDS)  to  effectively  counter  this  threat.  This  thesis  documents  the  process  that 
was  used  to  select  and  integrate  the  proposed  ASBMD  architecture. 
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EXECUTIVE  SUMMARY 


Recent  studies  suggest  that  China  is  developing  a  new  class  of  ballistic  missiles 
that  can  be  used  against  moving  targets,  such  as  ships.  One  such  technology  is  said  to  be 
able  to  cover  a  range  of  2,000  kilometers  (km)  and  operate  at  a  speed  of  Mach  10.  The 
threat  is  also  known  to  possess  the  capability  to  maneuver  both  during  the  midcourse  and 
terminal  phases  of  flight  for  the  purposes  of  guidance,  target  acquisition,  and 
countermeasures.  This  type  of  threat  could  greatly  impact  the  current  concept  of 
operations  (CONOPS)  of  United  States  (U.S.)  Navy  ships  and  alter  national  defense 
policies.  The  Chinese  technology  under  development  includes  an  anti-ship  ballistic 
missile  (ASBM)  based  on  a  variant  of  its  1,500  km-plus  range  DF-21/CSS-5  solid 
propellant  medium-range  ballistic  missile  (MRBM).  According  to  the  U.S.  Department  of 
Defense  (DoD),  if  supported  by  a  sophisticated  command  and  control  system  with 
accurate,  real-time  target  data  from  China's  growing  family  of  terrestrial  and  space-based 
sensors,  ASBMs  could  pose  a  significant  threat  to  U.S.  Navy  carrier  strike  groups  (CSGs) 
in  the  Western  Pacific.  ASBMs  would  offer  a  variety  of  operational  effects  for  Chinese 
maritime  strategy,  particularly  with  regard  to  missions  involving  Taiwan.  If  this  coverage 
is  achieved,  it  could  impose  significant  restrictions  on  U.S.  Naval  operations  during  a 
Taiwan  crisis  or  even  hold  U.S.  theater  land  bases,  such  as  those  on  Okinawa,  at  risk. 

While  there  are  currently  ballistic  missile  defense  solutions  capable  of 
intercepting  threats  in  the  midcourse  and  terminal  phases  of  flight,  no  comprehensive 
system  has  been  developed  to  counter  a  ballistic  missile  threat  that  can  (1)  maneuver 
upon  reentry  in  the  endoatmosphere  and  (2)  be  used  to  attack  a  moving  defended  area, 
such  as  a  U.S.  Navy  carrier  strike  group  (CSG). 

To  fulfill  this  need,  the  Anti-Ship  Ballistic  Missile  Defense  (ASBMD)  team 
conducted  research  and  developed  a  notional  architecture  for  a  system  of  systems 
solution  that  could  be  integrated  into  the  existing  Ballistic  Missile  Defense  System 
(BMDS)  to  effectively  counter  this  threat. 
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I.  INTRODUCTION 


A.  PROBLEM  DESCRIPTION 

A  recent  study  (Erickson  and  Yang,  2009)  suggests  that  China  is  developing 
ballistic  missiles  that  can  be  used  against  moving  targets,  such  as  ships.  One  such 
technology  is  said  to  be  able  to  cover  a  range  of  2,000  kilometers  (km)  and  operate  at  a 
speed  of  Mach  10.  The  threat  is  also  known  to  possess  the  capability  to  maneuver  both 
during  the  midcourse  and  terminal  phases  of  flight  for  the  purposes  of  guidance,  target 
acquisition,  and  countermeasures.  This  type  of  threat  could  greatly  impact  the  current 
concept  of  operations  (CONOPS)  of  United  States  (U.S.)  Navy  ships  and  alter  national 
defense  policies.  While  there  are  currently  ballistic  missile  defense  solutions  capable  of 
intercepting  threats  in  the  midcourse  and  terminal  phases  of  flight,  no  comprehensive 
system  has  been  developed  to  counter  a  ballistic  missile  threat  that  can  (1)  maneuver 
upon  reentry  in  the  endoatmosphere  and  (2)  be  used  to  attack  a  moving  defended  area, 
such  as  a  U.S.  Navy  carrier  strike  group  (CSG).  To  fulfill  this  need,  the  Anti-Ship 
Ballistic  Missile  Defense  (ASBMD)  team  will  propose  a  notional  architecture  for  a 
system  of  systems  that  could  be  used  to  effectively  counter  this  threat. 

One  example  of  such  a  threat  is  from  China,  which  is  pursuing  an  anti-ship 
ballistic  missile  (ASBM)  based  on  a  variant  of  its  1,500  km-plus  range  DF-21/CSS-5 
solid  propellant  medium-range  ballistic  missile  (MRBM).  According  to  the  U.S. 
Department  of  Defense  (DoD),  if  supported  by  a  sophisticated  command  and  control 
system  with  accurate,  real-time  target  data  from  China's  growing  family  of  terrestrial  and 
space-based  sensors,  ASBMs  could  pose  a  significant  threat  to  U.S.  Navy  CSGs  in  the 
Western  Pacific.  ASBMs  would  offer  a  variety  of  operational  effects  for  Chinese 
maritime  strategy,  particularly  with  regard  to  missions  involving  Taiwan.  If  this  coverage 
is  achieved,  it  could  impose  significant  restrictions  on  U.S.  Naval  operations  during  a 
Taiwan  crisis  or  even  hold  U.S.  theater  land  bases,  such  as  those  on  Okinawa,  at  risk. 
Two  key  technical  challenges  for  ASBM  development  are  target  acquisition  and  terminal 
phase  guidance;  these  technical  challenges  are  a  result  of  the  strict  timing  and  resource 
constraints  that  are  expected  during  the  terminal  phase  of  ballistic  flight. 


1 


Figure  1  shows  the  notational  maximum  ranges  of  the  DF-21/CSS-5  MRBM  from 
locations  in  mainland  China. 


Note:  Advertised  functional  ranges  of  the  Chinese  Ballistic  Missile  arsenal  are  depicted  here.  All 
ranges  include  limitations  due  to  terrain  and  required  flight  trajectories  (From  Erickson  and  Yang, 
2009). 

Figure  1.  Notional  Maximum  Ranges  of  DF-21/CSS-5 

Modem  ballistic  missiles  are  based  on  designs  that  have  been  used  since  World 
War  II.  They  can  be  launched  from  land  or  sea,  from  either  stationary  or  mobile 
platforms.  Ballistic  missiles  have  become  both  the  essential  long-range  artillery  of 
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modem  warfare  and  one  of  the  most  successful  means  of  exerting  international  pressure. 
The  threat  from  ballistic  missiles  has  grown  steadily  as  sophisticated  missile  technology 
has  become  available  on  a  wider  scale  to  countries  that  are  hostile  to  the  U.S.  and  its 
allies.  Figure  2  depicts  the  proliferation  of  these  types  of  ballistic  missile  threats 
worldwide  as  of  2006. 


Note:  Global  ballistic  missile  proliferation  has  increased  steadily  in  recent  decades.  Sophisticated 
missile  technology  is  now  more  widely  available  to  both  U.S.  allies  and  hostile  nations  (From 
Missile  Defense  Agency  (MDA),  2009,  April). 

Figure  2.  Evolving  Security  Environment,  2006 
B.  BACKGROUND  INFORMATION 

The  typical  ballistic  missile  uses  a  rocket  engine  to  give  it  an  initial  thrust  into  the 
air,  after  which  the  only  force  acting  on  it  is  gravity  to  bring  it  back  down  to  earth.  The 
rocket  engine  consists  of  some  form  of  fuel  and  oxidizer,  whether  solid  or  liquid  based. 
Since  ballistic  missiles  do  not  depend  upon  oxygen  from  the  atmosphere,  they  can  spend 
a  portion  of  their  flight  beyond  the  earth’s  atmosphere.  Longer  range  ballistic  missiles 
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spend  the  majority  of  their  flight  in  the  vacuum  of  space.  Figure  3  depicts  the  basic  stages 
of  flight  for  a  nominal  ballistic  missile. 


Note:  Ballistic  missile  flight  timelines  can  vary  by  missile  type,  but  any  threat  classified  as 
ballistic  follows  the  same  general  flight  profile  (From  Missile  Defense  101:  ICBM  Fundamentals, 
2007,  May  9). 

Figure  3.  Stages  of  Ballistic  Missile  Flight 

C.  BOOST  PHASE 

A  ballistic  missile’s  range  depends  on  the  ratio  between  the  thrust  generated  by  its 
engines  and  the  weight  that  the  thrust  must  overcome.  The  range  of  any  missile  can  be 
lengthened  by  reducing  the  load  that  it  must  carry.  If  the  missile  has  multiple  stages,  the 
lower  stages  will  drop  off  after  they  have  expended  their  fuel,  and  therefore,  lighten  the 
load.  At  a  designated  point  in  space,  the  last  engines  shut  off  or  bum  out,  which  ends  the 
boost  phase  of  the  missile’s  trajectory.  The  time  between  launch  and  engine  bum  out  can 
range  from  less  than  one  minute  to  over  five  minutes.  From  this  point  on,  the  laws  of 
physics  will  carry  what  remains  of  the  missile,  as  well  as  the  payload,  to  the  vicinity  of 
the  target. 
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1.  Midcourse  Phase 


The  second  phase  of  flight  for  a  ballistic  missile  is  the  midcourse  phase.  As  the 
missile  reaches  apogee,  the  section  that  carries  the  payload,  called  the  post-boost  vehicle, 
makes  final  adjustments  to  the  missile’s  course.  During  this  time,  missiles  that  carry 
multiple  warheads  eject  each  warhead  precisely  in  the  direction  of  its  individual  target. 
They  can  also  deploy  countermeasures,  such  as  decoys,  to  give  false  targets  to  enemy 
radars.  Some  post-boost  vehicles  are  designed  to  release  a  number  of  small  submunitions 
or  lethal  chemical/biological  compounds  instead  of  warheads  and  decoys.  As  warheads  or 
reentry  vehicles,  decoys,  and  the  remains  of  the  missile  coast  over  the  top  of  the  ballistic 
arc,  and  until  they  reach  the  upper  edges  of  the  atmosphere  above  the  target,  they  fall 
freely.  As  they  do  so,  these  items  gradually  spread  apart  along  their  individual  ballistic 
paths.  They  reach  maximum  speed  at  the  end  of  the  midcourse  phase,  before  the 
atmospheric  interference  associated  with  reentry  begins. 

2.  Terminal  Phase 

The  final  phase  of  flight  for  a  ballistic  missile  is  the  terminal  phase,  which  begins 
as  the  missile  reenters  the  endoatmosphere.  At  this  time,  air  molecules  begin  to  slow, 
heat,  and  bum  up  any  decoys  and  the  remains  of  the  post-boost  vehicle.  The  warhead  or 
reentry  vehicle  is  hardened  against  heat  and  pressure  and  designed  to  enter  the 
endoatmosphere  with  minimal  damage.  The  range  of  the  missile  determines  the  angle  at 
which  the  vehicle  or  warheads  fall  onto  the  target.  Warheads  from  the  longest  range 
missiles  arrive  at  shallow  angles  of  little  more  than  20  degrees,  while  shorter  range 
deliveries  can  impact  at  45  degrees. 

Typically,  the  warhead  of  a  ballistic  missile  consists  of  single  or  multiple  reentry 
vehicles.  These  reentry  vehicles  are  free-falling,  i.e.,  they  have  no  independent 
mechanism  that  will  direct  them  to  their  intended  target.  Their  accuracy  is  dependent  on 
the  calculations  made  before  launch,  sometimes  with  minor  course  corrections  being 
allowed  during  the  midcourse  phase  of  flight.  The  unique  characteristic  of  the  ASBM 
threat  is  that  it  will  employ  a  maneuvering  reentry  vehicle.  These  reentry  vehicles  should 
be  able  to  calculate  course  corrections  and  re-direct  themselves  to  the  intended  target, 
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such  as  a  ship  that  has  changed  position  since  the  time  that  the  threat  missile  was 
launched.  Figure  4  depicts  a  notional  ballistic  missile  trajectory  with  the  addition  of  a 
maneuvering  reentry  vehicle. 


Point  10  vary  trajectory 
in  mid  segment 


Terminal  guidance 

c 


initial  guidance 
(location  of  trie  aircraft 
carrier  when  the 
missile  was  launched) 


without  terminal 
guidance  (location 
of  the  aircraft 
carrier  with  mid 
segment  guidance) 


Trajectory  at 
launch  site 


D 

Target  point 
(current  location 
of  aircrall  carrier) 


Note:  Recent  threat  analysis  has  determined  that  multiple  countries  have  created  and  tested  a  new 
class  of  ballistic  missile  that  has  the  ability  to  maneuver  during  the  terminal  phase  of  ballistic 
flight  for  the  purpose  of  striking  moving  targets,  such  as  ships.  Defense  against  terminal 
maneuvers  represents  a  capabilities  gap  in  existing  combat  systems  (From  Erickson  and  Yang, 
2009). 

Figure  4.  Notional  ASBM  Trajectory  with  Maneuvering  Reentry  Vehicle 
D.  PROJECT  DESCRIPTION 

The  objective  of  the  proposed  ASBMD  System  is  to  detect,  track,  and  eliminate 
ASBM  threats.  The  objective  of  the  ASBMD  team  was  to  conduct  research  and  document 
a  proposed  architecture  for  a  system  of  systems  solution  that  could  be  implemented  to 
combat  the  evolving  ASBM  threat.  The  team  has  investigated  and  documented  potential 
solutions  to  address  this  threat,  while  ensuring  that  currently  fielded  capabilities  are  not 
degraded. 


The  scope  of  this  Capstone  Project  includes  the  research,  creation,  and 
documentation  of  the  total  system  architecture  that  may  be  used  to  combat  the  identified 
ASBM  threats.  The  following  constraints  were  identified  to  bound  the  system  that  the 
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team  created.  These  constraints  ensured  that  the  team  focused  the  requirements  and 
functionality  of  the  system  to  address  the  specific  problem  statement: 

•  ASBM  threats  will  be  launched  from  land. 

•  All  current  communication  mechanisms  required  for  conduct  of  the  ASBMD 
mission  are  operational  and  deployed  on  all  participating  systems. 

•  The  ASBMD  System  will  be  used  for  Ballistic  Missile  Defense  (BMD)  only. 

•  The  ASBMD  System  will  be  integrated  into  and  communicate  with  the 
existing  BMD  System  (BMDS). 

•  The  ASBMD  System  will  not  degrade  the  existing  BMD  network. 

•  The  ASBMD  System  design  will  comply  with  all  applicable  U.S.  military 
and/or  commercial  specifications  and  standards. 

E.  SYSTEM  ENGINEERING  APPROACH 

This  project  will  focus  on  the  Materiel  Solution  Analysis  phase  of  the  Defense 
Acquisition  Management  System,  using  Department  of  Defense  Instruction 
(DoDI)  5000.02  (2008,  December  8)  as  the  guide.  The  ASBMD  team  has  created  high- 
level  prototypes  of  several  key  documents  identified  in  the  Integrated  Defense 
Acquisition,  Technology,  and  Logistics  (AT&L)  Life  Cycle  Management  Evolutionary 
Acquisition  Program.  Figure  5  depicts  the  high-level  view  of  the  Defense  Acquisition 
Management  System,  with  the  area  addressed  by  this  project  shown  in  yellow. 
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Note:  Application  of  the  Defense  Acquisition  Management  System  process  is  key  to  ensuring  that 
all  aspects  of  program  acquisition  and  lifecycle  management  are  followed  throughout  system 
development  and  fielding  (From  DoDI  5000.02,  2008,  December  8). 

Figure  5.  ASBMD  Focus  within  the  Defense  Acquisition  Management  Process 

The  ASBMD  team  has  chosen  to  follow  the  “V”  model  version  of  the  Systems 
Engineering  Process  (SEP).  A  representation  of  the  “V”  model  for  the  Materiel  Solution 
Analysis  phase  is  provided  in  the  Integrated  Defense  Acquisition,  Technology,  and 
Logistics  Life  Cycle  Management  Chart  (Defense  Acquisition  University,  2009, 

June  15).  The  ASBMD  team  adapted  this  “V”  model  for  use  in  ASBMD  project 
development  as  shown  in  Figure  6.  The  “V”  model  approach  provides  a  detailed 
framework  and  development  guideline  that  enabled  the  team  to  analyze  this  capability 
gap  from  a  top-down  perspective.  The  “V”  model  is  constructed  to  enable  each  document 
or  analysis  effort  to  build  upon  the  previous  effort,  which  ensured  continuity  throughout 
the  project.  The  “V”  model  approach  also  contains  continuous  feedback  loops  during  all 
stages  of  analysis  and  development,  which  ensured  that  analysis  and  research  results  were 
incorporated  into  the  previous  documentation.  The  team  tailored  the  model  to  work 
within  the  limited  scope  and  time  allocated  for  the  project;  the  team  chose  the  specific 
documentation  and  artifacts  that  would  provide  the  most  benefit  to  the  project  and  those 
that  were  prerequisites  for  the  next  phase  of  research.  The  team  also  chose  to  limit  the 
scope  of  some  of  the  documents.  These  limited-scope  documents  were  designed  as 
excerpts,  indicating  that  the  document  contained  only  the  sections  that  the  team  thought 
were  required  to  allow  the  project  to  progress.  The  artifacts  that  were  identified  as 
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required  deliverables  are  detailed  in  the  following  chapters  and  are  listed  in  section  F 
below. 


Note:  The  “V”  model  process  is  used  to  ensure  that  each  artifact  is  created  from  a  top-down 
perspective,  ensuring  a  complete  and  robust  system  solution  that  is  fully  traceable  through  the 
system  engineering  process  (Adapted  from  Defense  Acquisition  University,  2009,  June  15). 

Figure  6.  Tailored  Materiel  Solution  Analysis  “V”  Model 
F.  DELIVERABLES 

The  ASBMD  team  provided  the  following  products  for  this  Capstone  project  as 
individual  deliverables,  which  are  excerpted  in  this  report: 


•  Problem  Statement:  Outlines  the  current  system  capabilities  and  threat 
assessments;  this  provides  details  of  the  current  system  functional  gap. 

•  Project  Management  Plan  (PMP)  (Appendix  A):  Details  the  approach  and 
schedule  for  developing  the  project  documentation. 
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•  CONOPS  (Appendix  B):  Describes  the  project  CONOPS  and  initial  plan  for 
integration  of  the  solution  into  existing  systems. 

•  Functional  Area  Analysis:  Identifies  operational  tasks,  conditions,  and 
standards  needed  to  accomplish  the  system  objectives. 

•  Functional  Architecture  (DoD  Architecture  Framework  (DoDAF)  products): 
Depicts  the  overall  system  alignment  and  functions  from  a  high-level  system 
view;  these  detail  interactions  within  the  system  and  identify  the  key  functions 
that  are  performed. 

•  Initial  Capabilities  Document  (ICD)  (Appendix  C):  Identifies  the  Key 
Performance  Parameters  (KPP)  and  Key  System  Attributes  (KSA)  (defined  in 
the  Chairman  of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  3170.01G,  Joint 
Capabilities  Integration  and  Development  System  (JCIDS)  (2009,  March  1)), 
which  define  the  most  critical  system  performance  elements.  This  document  is 
closely  tied  to  the  CONOPS  to  ensure  that  the  KPPs  identified  meet  the 
overall  need  of  the  system  as  originally  defined  during  the  analysis  phase. 

•  Analysis  of  Alternatives  (AoA)  Results:  Details  the  results  of  the  evaluation 
of  each  possible  system  alternative.  This  analysis  documents  the  ability  of  the 
alternatives  to  meet  KPPs  and  KSAs,  as  well  as  affordability  and  schedule 
constraints. 

•  Metrics,  Models,  and  Simulation  Analysis:  Details  the  models  and 
associated  metrics  used  to  validate  the  performance  of  the  chosen  system  to 
ensure  that  it  meets  the  established  Measures  of  Effectiveness  (MOEs), 
Measures  of  Performance  (MOPs),  and  KPPs. 
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II.  SYSTEM  ANALYSIS 


A.  OVERVIEW 

This  chapter  describes  the  artifacts  and  analyses  that  the  team  created  during  the 
functional  system  analysis  of  conceptual  system  architectures.  The  following  sections 
detail  the  process  that  was  followed  as  the  team  derived  high-level  requirements  from 
stakeholder  inputs  and  decomposed  those  system  requirements  into  the  functional 
components  of  the  system. 

B.  STAKEHOLDER  ANALYSIS 

To  ensure  that  the  system  engineering  process  was  applied  in  a  manner  that  would 
yield  a  solution  to  thoroughly  address  the  needs  statement  and  fill  the  identified 
capability  gap,  the  team  obtained  inputs  from  interested  stakeholders.  The  stakeholders 
were  identified  as  persons  who  could  provide  insight  about  technology  needs  from  the 
fleet,  program  office,  and  end  user  perspectives.  Inputs  from  these  individuals  were 
obtained  via  meetings,  briefings,  and  surveys.  Their  insight  was  used  to  frame  the 
analysis  products  and  was  also  captured  in  the  weighting  of  needs  that  was  applied  during 
the  Functional  System  Analysis  (FSA). 

C.  FUNCTIONAL  SYSTEM  ANALYSIS 

An  FSA  is  the  process  that  the  team  used  to  derive  the  key  functional  artifacts 
required  to  build  the  notional  ASBMD  architecture  candidates.  This  analysis  began  with 
a  high-level  initial  needs  statement  that  was  similar  to  the  problem  statement  that  the 
team  developed  during  the  initial  stages  of  the  project.  The  next  step  in  the  process  was  to 
create  the  operational  documentation  that  would  help  bound  the  system;  this  operational 
documentation  consisted  of  the  CONOPS  and  Design  Reference  Missions  (DRMs). 

Using  the  operational  documentation,  the  team  was  able  to  derive  high-level  system 
requirements  and  MOEs/MOPs  and  perform  functional  allocation,  as  well  as  create 
functional  flow  diagrams  that  detail  the  interactions  of  the  system.  Each  step  of  the  FSA 
process  is  detailed  in  the  following  sections  of  this  chapter. 
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Figure  7  depicts  the  requirements  generation  process  flow  used  to  ensure  the 
alignment  of  the  system  with  the  needs  statement. 


Note:  Flow  of  requirements  generation  is  key  to  ensuring  that  the  final 

product  meets  stakeholder  needs  and  operational/functional  requirements. 

Figure  7.  ASBMD  Requirements  Generation  Process 
1.  Concept  of  Operations 
a.  Purpose 

The  primary  function  of  the  ASBMD  CONOPS  document  was  to  identify  the 
scope  of  work  for  the  investigation  and  documentation  of  a  system  architecture  that  could 
be  used  to  implement  a  system  to  defend  against  ASBM  threats.  It  detailed  the 
operational  needs  and  mission  requirements  for  such  a  system.  It  also  discussed  potential 
gaps  in  the  current  systems  being  used  to  detect,  track,  and  eliminate  the  latest  ballistic 
missile  and  ASBM  threats. 


The  ability  to  detect,  track,  and  eliminate  the  identified  ASBM  threat  will  require, 
at  a  minimum,  upgrades  to  existing  systems.  The  primary  goal  of  the  team  was  to 
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perform  detailed  analyses  to  determine  the  most  robust  system  of  systems  to  perform  the 
full  detect-to-engage  sequence.  To  achieve  this  goal,  the  team  would  investigate  both  the 
use  of  existing  systems  and  the  development  of  new  technologies,  as  appropriate,  to 
fulfill  all  required  functions. 

Due  to  the  maturity  of  existing  capabilities  to  detect  and  track  ballistic  missiles 
during  the  boost  phase,  the  ASBMD  team  focused  the  detailed  analysis  and  architecture 
documentation  on  the  post-boost  phases  of  flight:  tracking  and  eliminating  the  threats 
during  later  phases  of  the  ballistic  flight-path.  Refer  to  Figure  3  for  a  graphical 
representation  of  a  ballistic  missile  trajectory  and  its  stages. 

b.  Threat  Analysis  of  the  Ballistic  Missile  Trajectory 

Intercepting  a  missile  in  its  boost  phase  is  an  ideal  solution  for  BMD.  If  the 
missile  is  carrying  a  chemical,  biological,  or  nuclear  weapon,  the  debris  would  most 
likely  fall  on  the  country  that  launched  the  missile.  At  this  altitude,  the  threat  would  not 
have  obtained  enough  velocity  to  reach  its  intended  target,  eliminating  the  need  to 
completely  destroy  the  threat  missile’s  warhead.  Although  attacking  a  missile  while  it  is 
struggling  against  the  earth’s  gravity  is  ideal,  it  poses  several  significant  challenges  to  a 
defense  system.  First,  the  boost  phase  is  relatively  short,  limiting  the  amount  of  time  that 
sensors  will  have  to  detect  a  launch  and  relay  accurate  information  about  the  missile. 
Second,  an  interceptor  missile  would  have  to  be  very  close  or  extremely  fast  to  intercept 
the  accelerating  missile  and  properly  configured  to  intercept  a  target  in  the  boost  phase. 
When  possible,  for  the  global  coverage  and  protection  against  more  lethal  payloads  that  it 
can  provide,  a  capability  to  intercept  a  missile  near  its  launch  point  is  always  preferable 
to  attempting  to  intercept  that  same  missile  closer  to  its  target. 

The  midcourse  phase  allows  the  largest  opportunity  to  intercept  an  incoming 
missile.  At  this  point,  the  missile  has  stopped  thrusting,  and  it  follows  a  more  predictable 
path.  Depending  on  the  interceptor  launch  location,  multiple  interceptors  could  be 
launched  with  a  delay  between  them  to  determine  if  the  initial  attempts  were  successful. 
Due  to  the  increased  engagement  timeline,  fewer  interceptor  sites  are  needed  to  defend 
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larger  areas.  A  longer  period  in  space  provides  an  attacking  missile  the  opportunity  to 
deploy  countermeasures  against  a  defensive  system,  if  equipped  to  do  so,  but  the 
defensive  system  also  has  more  time  to  observe  and  discriminate  countermeasures  from 
the  warhead. 

The  terminal  phase  of  ballistic  missile  flight  is  normally  less  than  one  minute  in 
duration.  At  this  point,  defensive  systems  must  be  very  close  to  the  threat  missile’s  target 
in  order  to  defend  against  the  attack.  Countermeasures  are  less  of  a  challenge  in  this 
phase,  as  they  usually  fall  at  a  slower  rate  than  the  warhead  or  are  burned  up  as  they 
reenter  the  atmosphere.  Defensive  systems  designed  for  the  terminal  phase  are  most 
effective  in  protecting  nearby  troop  concentrations,  ports,  airfields,  and  staging  areas. 
Currently  fielded  terminal  phase  interceptors  have  not  been  proven  effective  against 
maneuvering  reentry  vehicles.  More  information  is  provided  in  the  next  section  about 
current  capabilities  the  U.S.  has  to  counter  ballistic  threats. 

c.  Existing  Capabilities  to  Address  the  Threat 

Multiple  systems  are  currently  deployed  as  part  of  the  BMDS  that  are  designed  to 
combat  ballistic  missile  threats.  Each  individual  system  is  designed  to  focus  on  specific 
phases  of  the  ballistic  missile  trajectory.  When  integrated  within  the  BMDS,  these 
systems  provide  a  layered  defense  capability.  Some  examples  of  these  systems  and  their 
primary  functions  are  provided  in  Table  1. 
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Table  1.  Existing  BMD  Systems 

Note:  The  existing  BMDS  is  a  layered  network  comprised  of  a  variety  of  systems  and 
technologies.  These  systems  provide  BMD  coverage  in  a  variety  of  scenarios  and  ranges  for  a 
multitude  of  ballistic  missile  threats. 


System  Name 

Phase 

Function 

Weapon 

Systems 

Kinetic  Energy  Interceptor  (KEI) 

Boost 

Intercept 

Airborne  Laser  (ABL) 

Boost 

Intercept 

Ground-Based  Interceptor  (GBI) 

Midcourse 

Intercept 

Standard  Missile  (SM)-3  Block  IA 

Midcourse 

Intercept 

Patriot  Advanced  Capability-3  (PAC-3) 

Terminal 

Intercept 

SM-2  Block  IVA  (SM-T) 

Terminal 

Intercept 

Terminal  High  Altitude  Area  Defense 
(THAAD) 

Terminal 

Intercept 

Arrow  Weapon  System 

Terminal 

Intercept 

Sensors 

Cobra  Dane  Radar 

Boost/Midcourse 

Detection/T  racking 

Cobra  Judy  Radar 

Boost/Midcourse 
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Space  Tracking  and  Surveillance  System 
(STSS) 

All 

Detection/Tracking 
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The  Aegis  BMD  System  is  an  example  of  a  successful  BMD  system.  This  system 
uses  both  remote  and  local  detection/tracking  via  ground  and  satellite-based  sensor 
systems,  as  well  as  shipboard  sensors.  Once  an  external  network  sensor  detects  a  threat 
and  transitions  it  to  a  radar  track,  the  remote  systems  can  “hand  over”  the  threat  track  to 
the  shipboard  AN/SPY- 1  radar  for  organic  (ownship)  tracking  and  engagement.  The 
handover  of  the  threat  track  is  accomplished  by  having  the  remote  tracking  system 
calculate  a  flight  trajectory  of  the  threat  track  and  then  cue  the  organic  radar  to  a  point  in 
space  where  the  threat  will  be  at  a  given  time.  This  method  requires  direct,  high-speed 
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communication  between  all  elements  in  the  system.  The  Aegis  BMD  system  also  relies 
heavily  on  the  availability  of  the  Standard  Missile  (SM)-3  or  SM-2-Block  IV  missile  to 
engage  and  destroy  ballistic  targets  in  the  midcourse  and  terminal  phases,  respectively. 
These  systems  currently  have  no  alternate  or  complementary  shipboard  weapons  that 
could  be  used  to  combat  a  ballistic  threat.  Figure  8  is  a  pictorial  representation  of  the 
Missile  Defense  Agency’s  BMDS,  which  includes  the  Aegis  BMD  system. 
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None  Of  This  BMD  Capability  Existed  In  June  2004 


Note:  Existing  U.S.  BMD  assets  as  of  2007  are  shown.  The  emerging  ballistic  missile  threat  has 
created  an  urgent  need  for  a  shift  in  U.S.  policy  to  dedicate  resources  to  the  acquisition  and 
fielding  of  BMD  network  assets  (From  Sanders,  2007,  June  28). 

Figure  8.  Pictorial  Representation  of  the  MDA  BMDS 

Multiple  systems  are  currently  deployed  or  in  development  that  have  the  ability  to 
detect  and  track  ballistic  missiles  during  boost,  midcourse,  and  terminal  phases.  Coupled 
with  the  existing  system  that  provides  the  capability  to  engage  these  threats  during  all 
ballistic  phases,  the  U.S.  has  a  robust  system  design  that  has  a  successful  track  record 
during  test  intercepts  of  ballistic  targets. 


d.  Shortcomings  of  Current  Systems 

As  previously  described,  the  current  BMD  systems  rely  heavily  on  the  ability  of 
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remote,  internal,  and  on-board  sensors  to  predict  and  relay  the  flight  path  trajectory  of  the 
ballistic  threat.  The  anti-ship  threats  that  are  being  introduced  have  been  designed  to 
exploit  limitations  in  the  current  deployed  capabilities.  Using  the  example  threat  given  in 
the  problem  statement,  the  threat  can  be  traveling  in  excess  of  Mach  10  at  the  time  of 
reentry  and  can  maneuver  during  the  terminal  portion  of  flight,  altering  its  aimpoint  and 
ultimately  forcing  a  defense  system  to  estimate  a  false  trajectory.  Given  the  current 
capabilities,  the  ability  of  the  system  to  predict  the  ultimate  flight  path  of  these  threats 
becomes  impossible. 

Another  shortcoming  of  the  current  systems  is  that,  for  sea-based  intercepts,  they 
rely  exclusively  on  the  availability  of  ships  configured  with  the  Aegis  BMD  Weapon 
System  and  loaded  with  SM-3  or  SM-2-Block  IV  missiles.  Only  3  cruisers  and 
15  destroyers  are  configured  to  conduct  Aegis  BMD  missions  as  of  2009,  so  these  assets 
must  be  strategically  located  to  provide  adequate  coverage.  While  the  SM-3  Block  IA  is  a 
full-rate  production  missile,  it  is  only  capable  of  conducting  midcourse  intercepts.  The 
Sea-Based  Terminal  (SBT)  terminal-phase  intercept  capability  is  provided  by  use  of  the 
modified  SM-2  Block  IV,  also  known  as  the  SM-T  missile.  The  modifications  that  were 
made  to  the  SM-2  Block  IV  to  achieve  the  SBT  capability  transformed  the  weapon  from 
an  Anti- Air  Warfare  (AAW)  interceptor  to  a  BMD  interceptor.  These  changes  enabled 
the  missile  to  intercept  high-velocity  ballistic  threats  in  the  last  moments  of  their  flight. 
The  SM-T  missile  is  no  longer  in  production,  constraining  the  SBT  capability  to  the 
remaining  inventory  in  the  near  term.  A  far-term  SBT  capability  using  a  different  missile 
is  under  development,  but  will  not  be  fielded  for  several  years.  Given  the  minimal  system 
availability,  a  significant  operational  risk  exists  for  most  CSGs  when  operating  within  the 
expected  range  of  ASBM  threats. 

Based  on  the  capabilities  deployed  to  date,  if  ASBM  threats  are  put  into  full-rate 
production,  a  fundamental  shift  would  be  needed  in  the  current  operational  CONOPS  for 
the  U.S.  Navy.  Without  a  robust  and  reliable  system  to  counter  these  threats,  U.S.  Navy 
CSGs  would  be  required  to  drastically  reduce  their  ability  to  operate  within  close  vicinity 
of  countries  that  have  the  threat  production  capabilities. 
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e.  Priority  of  New  Features 

The  ASBMD  System  will  perform  the  detection-through-engagement  portion  of 
the  sequence  for  an  ASBM  threat.  The  specific  benefits  of  the  ASBMD  System  will  be  its 
ability  to  track  and  eliminate  or  avoid  maneuvering  threats  during  the  midcourse  or 
terminal  phases  of  flight.  The  Navy  will  benefit  from  a  robust  architecture  that  can 
provide  engagement-quality  data  to  a  system  that  can  be  used  to  eliminate  the  threat 
during  the  later  phases  of  flight. 

The  ASBMD  team  has  prioritized  the  key  system  features,  taking  into 
consideration  existing  systems  that  can  perform  portions  of  the  mission.  As  stated  earlier, 
multiple  systems  are  being  developed  that  have  the  ability  to  detect  and  engage  ballistic 
missiles  during  both  the  boost  and  midcourse  phases  of  ballistic  missile  flight;  therefore, 
the  priority  of  the  proposed  system  and  analysis  is  the  tracking  and  engagement  of  ASBM 
threats  during  the  post-boost  phases  of  flight.  Specifically,  the  team  has  prioritized 
engagement  of  the  threat  during  the  midcourse  phase  of  flight  as  the  highest  priority  of 
the  proposed  system;  a  midcourse  intercept  would  eliminate  the  threat  before  it  can 
conduct  its  maneuver. 

For  operations  within  the  terminal  phase  of  flight,  there  are  two  key  system 
functions — tracking  and  engagement — that  have  also  been  prioritized  for  assessment.  The 
ASBMD  team  prioritized  tracking  of  the  reentry  vehicles  as  the  highest  priority,  and  then 
the  engagement  of  the  threats  as  the  second  highest.  The  ASBMD  System  is  dependent 
on  the  ability  of  the  system  to  provide  engagement  quality  data  to  engage  and  eliminate 
the  threats;  therefore,  accurate  tracking  of  the  threats  is  of  the  utmost  importance. 

f.  Functional  Analysis  Results 

The  ASBMD  capability  will  be  achieved  by  a  system  of  systems  that,  to  meet  its 
mission  requirements,  is  comprised  of  a  minimum  set  of  components.  Components 
considered  and  analyzed  included:  radar,  electro-optic  (EO)/infrared  (IR)  sensors,  passive 
electronic  warfare  sensors,  communications/link  architecture,  command  and  control 
systems,  decoys,  electronic  countermeasures,  and  one  or  more  weapon  systems. 
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A  preliminary  functional  analysis  resulted  in  a  list  of  the  primary  system 
functions,  as  follows: 

•  Search:  The  system  will  be  capable  of  conducting  search  functions  in 
self-defense  and  BMD  modes. 

•  Detect:  The  system  will  be  capable  of  detecting  an  incoming  threat 
organically  (using  ownship  sensors).  The  system  will  also  be  capable  of 
initiating  engagement  sequences  based  on  remote  sensor  detection  and 
track  hand-off. 

•  Acquire  Track:  The  system  will  be  capable  of  conducting  organic  track 
acquisition  and  communicating  that  track  to  the  BMDS.  The  system  will  also 
be  capable  of  launching  on  remote  track  data  (with  eventual  acquisition  of  the 
track  organically)  or  full  engagement  on  remote  track  data  (with  no  organic 
track  acquisition). 

•  Planning:  The  system  will  be  capable  of  communicating  with  BMDS 
resources  for  determination  of  the  best  use  of  local  radar  and  weapon 
resources. 

•  Identification:  The  system  will  be  capable  of  identifying  the  threat  type  via 
on-board  sensor  discrimination  and  will  not  engage  on  countermeasures. 

•  Engagement:  The  system  will  be  capable  of  executing  an  engagement  against 
the  incoming  threat. 

•  Kill  Assessment  (KA):  The  system  will  provide  KA  data  to  the  operator  and 
the  BMDS  so  that  a  determination  of  kill  and  the  potential  for  reengagement 
can  be  assessed. 

The  system  must  be  capable  of  surviving  and  operating  in  the  tactical 
environment  and  will  meet  all  requirements  for  system  certification  and  fielding.  Ships 
with  this  capability  can  be  deployed  in  any  operational  area  necessary  to  provide 
coverage  in  the  ASBMD  mission  area.  The  system,  as  designed,  must  interface  with  the 
larger  BMDS  for  the  purposes  of  battle  management  and  command  and  control.  It  will 
interface  with  its  battlegroup  or  ships-in-company  for  local  fire  control,  radar  resource, 
and  weapon  management. 
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Currently,  there  is  no  single  solution  to  address  the  ASBM  threat.  In  designing  a 
system-of- systems  solution,  a  key  objective  of  this  project  was  to  consider  technologies 
that  would  complement  a  layered  approach  that  takes  advantage  of  remote  and  forward- 
based  capabilities  as  well  as  organic/ownship  capabilities.  Any  leveraging  of  existing 
technology  will  require  that  the  systems  are  made  more  robust  to  meet  requirements  for 
sensor  function,  detection,  and  BMDS  interfaces.  The  final  aim  of  the  system  design  is  to 
propose  a  reliable,  compatible,  and  interoperable  ASBMD  functionality  to  support 
defense  of  critical  assets  and  mission  areas  to  the  Navy. 

2.  Design  Reference  Mission  Profiles  and  Scenarios 

a.  Purpose 

As  defined  by  Pace  (2000),  a  DRM  defines  the  specific  projected  threat  and 
baseline  operating  environment  for  a  given  system;  these  may  range  from  a  single¬ 
purpose  weapon  system  to  a  multi-mission  platform,  or  to  a  multi-system,  multi-platform 
system  of  systems.  The  ASBMD  DRM  provides  a  notional  description  of  deployed 
operations  for  the  mission  as  described  in  the  ASBMD  CONOPS.  It  is  primarily  an 
engineering/design  tool  used  to  support  systems  engineering  activities  by  identifying 
significant,  design-driving  operational  elements  and  characterizing  them  to  the  level  of 
detail  necessary  to  assess  their  design  impact.  The  DRM  is  intentionally  modular  to  allow 
the  team  to  tailor  or  modify  the  scenario  and  its  components  over  time  in  order  to  update 
operational  and  warfighting  requirements  and  prospective  solutions.  To  this  end,  the 
DRM  is  envisioned  as  an  evolutionary  document  that  can  be  revised  throughout  the 
acquisition  process.  The  DRM  is  comprised  of  two  distinct  components:  Design 
Reference  Mission  Profiles  (DRMP)  and  Design  Reference  Mission  Scenarios  (DRMS); 
each  component  will  be  detailed  in  the  following  sections. 

b.  DRM  Profiles 

The  DRMP  is  a  matrix  of  the  best,  expected,  and  worst  values  for  each  of  the 
operational  conditions  for  the  ASBMD  system.  The  DRMP  helped  bound  the  operational 
capabilities  of  the  system  by  defining  the  overall  timing  requirement  for  each  of  the  sub¬ 
functions  of  the  ASBMD  system. 
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The  example  DRMP  is  shown  below  in  Table  2. 


Table  2.  DRMP  for  the  ASBMD  System 


Note:  The  DRMP  is  a  matrix  of  the  best,  expected,  and  worst  values  for  each  of  the  operational 
conditions  to  which  the  concept  architecture  will  be  exposed.  The  DRMP  helps  to  ensure  that  the 
system  requirements  cover  the  operational  context  of  the  system. 


Event 

Required 

Equipment 

Factors 

Condition 

Best 

Expected 

Worst 

Missile  Launch 

N/A 

#  of  Missiles 

1 

2 

4 

#  of  Locations 

1 

1 

2 

Missile  Detection 

Organic/Nonorganic 
Detection  System 

Time  to  Detect 

Is 

10s 

No 

Detection 

Ship  Time  to 
Detect 

Is 

20s 

No 

Detection 

Missile  Tracking 

Organic/Nonorganic 
Tracking  System 

#  of  Missiles 

1 

2 

6 

Compute  Fire 
Control  Solution 

Organic/Nonorganic 

System 

Time  to  Compute 

Is 

3s 

10s 

Transmit 

Kill  Order 

Communication 

Network 

Time  to  Transmit 

Is 

5s 

10s 

Missile 

Engagement 

Participating  Units 

Weapons 

Available 

5 

3 

1 

Missile 

Kill  Assessment 

BDA  Capable 

System 

Operational 

Yes 

Yes 

No 

Missile 

Re-Engagement 

Participating  Units 

Weapons 

Available 

Yes 

Yes 

No 

c.  DRM  Scenarios 

The  DRMS  are  graphical  representations  of  the  DRMP  criteria.  The  DRMS  that 
the  team  created,  along  with  the  general  explanation  of  each,  are  shown  below. 

The  best  scenario  in  DRM  terms  is  one  in  which  the  ideal  conditions  for  operation 
of  the  system  are  present.  For  ASBMD,  the  best  case  scenario  consists  of  the  following 
conditions: 


•  A  single  threat  is  launched  from  a  known  launch  site. 

•  All  participating  defense  systems/units  are  online  and  fully  operational. 
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Environmental  factors  do  not  impact  performance. 


Figure  9  depicts  the  best  case  scenario  for  the  ASBMD  system. 


Note:  The  best  case  DRMS  represents  the  minimal  threat  environment  that  the  system  will 
encounter.  Using  the  best  case  DRMS  will  help  bound  the  minimum  capability  required  of  a 
system  in  the  optimal  environment. 

Figure  9.  DRMS  1  (Best)  for  ASBMD 

The  expected  scenario  is  depicts  the  conditions  that  the  ASBMD  System  is  most 
likely  to  encounter  in  the  tactical  environment.  Conditions  in  this  scenario  are  neither 
ideal  nor  dire.  The  conditions  for  the  expected  scenario  are  as  follows: 

•  Multiple  incoming  threats  are  launched  from  one  launch  site. 

•  Satellite  coverage  is  provided  for  one  launch  site. 

•  The  CSG  experiences  average  environmental  conditions  and  their  associated 
performance  impacts. 

•  Three  defense  units  are  participating:  Satellite,  Forward-Based  Sensor,  and 
Firing  Ship. 
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Figure  10  depicts  this  scenario. 


Note:  The  expected  case  DRMS  represents  the  nominal  threat  environment  that  the  system  will 
encounter.  This  scenario  is  used  to  derive  the  objective  values  for  many  of  the  system  performance 
requirements. 

Figure  10.  DRMS  2  (Expected)  for  ASBMD 

The  worst  case  scenario  is  a  depiction  of  the  worst  operational  environment  that 
the  ASBMD  System  is  expected  to  encounter.  The  conditions  for  this  scenario  are  as 
follows: 

•  Multiple  incoming  threats  are  launched  from  multiple  launch  sites. 

•  Participating  units  experience  performance  degradation  due  to  adverse 
environmental  conditions. 

•  Detection  and  tracking  of  threats  is  unreliable. 
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Figure  1 1  shows  this  scenario  for  ASBMD. 


Note:  The  worst  case  DRMS  represents  the  most  taxing  threat  environment  that  the  system  will 
face.  This  scenario  is  used  to  determine  the  upper  bounds  of  the  system  capabilities,  including 
bounding  values  for  computer  processing  and  network  loading  requirements. 

Figure  11.  DRMS  3  (Worst)  for  ASBMD 
3.  Initial  Capabilities  Document 

a.  Purpose 

The  primary  function  of  the  ASBMD  ICD,  provided  as  Appendix  C,  was  to 
describe  the  need  for  a  material  approach  to  fill  the  functional  gap  within  the  current 
BMDS  that  is  created  when  ASBM  threats  are  introduced  into  the  arsenals  of  enemy 
combatants.  This  document  defines  the  existing  capability  gap  in  terms  of  the  functional 
areas  affected  and  also  describes  why  non-material  changes  alone  are  not  adequate  to 
fully  provide  the  needed  capability. 

b.  Functional  Requirements 

The  following  is  a  list  of  high-level  functional  requirements  that  was  used  as  the 
basis  for  the  follow-on  system  analysis  and  decomposition.  It  is  an  excerpted  list  of 
requirements  provided  as  part  of  the  ICD,  and  should  not  be  viewed  as  a  complete  list  of 
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requirements  that  the  system  must  meet. 


•  The  ASBMD  System  shall  be  capable  of  sending,  receiving,  and  processing 
intelligence  reporting  messages  to  be  used  for  situational  awareness  related  to 
ballistic  missile  flight  path.  (This  includes,  but  is  not  limited  to,  the  ability  to 
receive  and  process  Global  Command  and  Control  System  Maritime 
(GCCSM),  Tactical  Data  Link  (TDL)  (Link-1 1,  Link- 16),  and  Data 
Distribution  System  (DDS)  messages.) 

•  The  ASBMD  System  shall  process  received  intelligence  messages  and  create 
radar  search  sectors  to  be  used  by  both  on-board  and  off-board  sensors. 

•  The  ASBMD  System  shall  be  capable  of  tracking  no  less  than  10  vehicles 
during  the  midcourse  and/or  terminal  phases  of  missile  flight  path.  Tracking 
shall  include  the  production  and  dissemination  of  engagement  quality  data. 

•  The  ASBMD  System  shall  be  capable  of  near  simultaneous  engagement  of  no 
less  than  two  ballistic  vehicles. 

•  The  ASBMD  System  shall  be  capable  of  performing  Launch  on  Remote 
(LoR)  using  fire  control  quality  data  from  the  BMDS  network. 

•  The  ASBMD  System  shall  be  compatible  with  the  ship’s  requirement  and 
capability  to  perform  both  self-defense  (i.e.,  AAW)  and  BMD  missions. 

•  The  ASBMD  System  shall  have  a  Mean  Time  Between  Failures  (MTBF)  that 
is  greater  than  or  equal  to  the  MTBF  of  the  existing  BMDS  architecture  into 
which  the  ASBMD  System  will  be  integrated. 

•  The  ASBMD  System  shall  have  the  ability  to  perform  high  fidelity  object 
discrimination. 

•  The  ASBMD  System  shall  have  the  ability  to  perform  localization. 

•  The  ASBMD  System  shall  have  the  capability  to  perform  threat  identification. 

c.  Measures  of  Effectiveness  and  Measures  of  Performance 

MOEs  and  MOPs  are  quantitative  measures  that  give  some  insight  into  how 
effectively  a  unit  must  perform  under  the  operational  conditions  defined  in  the  CONOPS 

and  detailed  in  the  DRMs.  The  MOEs  for  this  project  were  defined  primarily  through  the 
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use  of  stakeholder  inputs,  as  described  earlier  in  this  chapter.  The  ASBMD  team  defined 
the  MOPs  using  the  nominal  values  that  were  obtained  during  the  initial  investigation  and 
analysis  portion  of  the  project.  The  key  ASBMD  System  MOEs  and  MOPs  are  identified 
in  Tables  3  and  4,  respectively.  As  with  the  system  requirements,  these  lists  should  not  be 
considered  complete,  as  they  are  excerpts  from  the  documents  that  were  used  to  help 
bound  the  system. 


Table  3.  ASBMD  MOEs 


Note:  MOEs  are  defined  by  stakeholder  inputs.  They  are  used  to  measure  the  ability  of  the  concept 
architectures  to  meet  the  operation  needs  of  the  overall  system. 


MOE 

Description 

Objective 

Pd 

Probability  of  detection 

0.95 

Pf 

Probability  of  false  alarm 

0.005 

Pkhi 

Probability  of  kill 

0.97 

pw 

Probability  of  correct  identification 

0.9997 

P  dis 

Probability  of  correct  discrimination 

0.9997 

MaxTgteng 

Maximum  number  of  targets  engaged 

2.0 

Probability  of  information  exchanged 

0.9999 

MaxTgttrk 

Maximum  number  of  targets  simultaneously  tracked 

10.0 

Table  4.  ASBMD  MOPs 


Note:  MOPs  are  defined  by  stakeholder  inputs.  They  are  used  to  provide  a  measurement  of  the 
ability  of  the  system  to  perform  in  a  system  of  systems  context. 


MOP 

Description 

Objective 

Ttrk 

Track  formulation  time 

0.5  sec 

Tdet 

Organic  detection  time 

6  sec 

Teng 

Engagement  time 

60  sec 

T re-eng 

Re-engagement  time 

15  sec 

T  kill 

Time  to  conduct  kill  assessment 

10  sec 

Neng 

Number  of  simultaneous  engagements 

2 
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4.  Functional  Analysis  and  Allocation 

Functional  Analysis  is  the  process  by  which  the  team  took  the  identified  key 
system  requirements  (How's)  and  the  need  statements  ( What's )  and  combined  them  into  a 
Quality  Function  Deployment  (QFD)  matrix.  Each  need  statement  was  weighted  by  using 
the  inputs  solicited  during  the  stakeholder  analysis  portion  of  the  project.  Next,  the 
requirements  were  rated  against  the  needs  statements;  each  requirement  was  assigned  a 
numerical  rating  between  one  and  ten  that  corresponds  to  the  level  of  influence  that  it  has 
in  fulfilling  the  identified  needs.  The  mapping  of  requirements  to  mission  needs  is 
depicted  in  Table  5.  The  team  used  this  process  to  assist  in  the  allocation  of  requirements 
to  the  identified  functions  of  the  system.  Each  function  will  be  detailed  in  the  following 
sections  of  this  document  and  is  depicted  in  Table  6. 
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Table  5.  Functional  Analysis 


Note:  Functional  Analysis  ensures  that  each  identified  functional  requirement  is  mapped  to  an 
identified  need.  Each  need  is  weighted  to  help  drive  the  functional  prioritization  of  the  system. 


Functional  Analysis 

Requirements  (How’s) 

Needs 

(What’s) 

Weights 

Capable  of 
processing 
received 
intelligence 
messages 
and  creating 
radar  search 
sectors  for 
use  by  on¬ 
board  and 
off-board 

sensors 

Capable  of 
performing 
launch  on 
remote  using 
fire  control 
quality  data 
from  the 
BMDS 
network 

Capable  of 
performing 
both  self- 
defense  and 
BMD 
missions 

Capable  of 
an  MTBF  that 
is  greater 
than  or  equal 
to  the  MTBF 
of  the 
existing 

BMDS 

Capable  of 
sending, 
receiving  and 
processing 
intelligence 
reporting 
messages  to 
be  used  for 
situational 

awareness 

Capable  of 
near 

simultaneous 
engagement 
of  no-less- 
than  two 
ballistic 
vehicles 

Protect  other 
assets  from 
ballistic  missiles 

0.275 

8 

7 

8 

5 

8 

9 

Interoperable  with 
BMDS 

0.15 

9 

8 

4 

5 

9 

3 

Stand-alone  BMD 
capability 

0.15 

3 

3 

9 

3 

3 

9 

Destroy  ballistic 
missiles  with  a 
high  probability  of 
kill 

0.275 

7 

7 

9 

5 

6 

9 

Operate  across  a 
wide  range  of 
environmental 
conditions 

0.15 

5 

5 

7 

8 

9 

7 

Sum 

1 

Weighted 

Performance 

16.4 

16.0 

20.6 

16.0 

19.4 

20.7 

109.1 

Percentage 

0.151 

0.147 

0.189 

0.147 

0.178 

0.190 
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Table  6.  Functional  Allocation 


Note:  Functional  Allocation  is  the  mapping  of  system  functions  to  the  known  components  of  the 
functional  architecture.  This  mapping  ensures  that  the  system  under  analysis  is  sufficiently 
bounded  and  that  there  is  no  unintentional  overlap  of  functions. 


Components 

Functions 

Nonorganic 

Assets 

Organic 

Radar 

Fire 

Control 

System 

Data 

Transfer 

System 

BMDS 

Receive/Transmit  Intelligence  Cueing 

X 

Detection 

X 

X 

Classification 

X 

X 

Tracking 

X 

X 

Discrimination 

X 

X 

Identification 

X 

Decide  and  Assess 

X 

X 

Engage  Ballistic  Missile 

X 

Perform  Kill  Assessment 

X 

X 

5.  Functional  Flow  Diagrams 

The  proposed  ASBMD  System  is  scoped  as  a  system  of  systems  that  provides  a 
set  of  value-added  functions  within  the  existing  BMDS.  The  system’s  objective  is  to 
provide  increased  capabilities  to  defend  against  and  eliminate  ASBM  threats.  The 
proposed  system  will  be  fully  integrated,  interrelated,  and  interoperable  with  the  existing 
BMDS.  As  a  result,  the  ASBMD  System  will  be  an  information  environment  within  an 
existing  combat  system  comprised  of  interoperable  computing  and  communication 
components. 

As  stated  earlier,  the  ability  of  an  ASBM  threat  to  maneuver  during  its  terminal 
phase  of  flight  is  what  differentiates  it  from  a  typical  ballistic  missile.  Due  to  the  distinct 
operational  attributes  of  the  ASBM  threat,  the  unique  functionality  of  the  ASBMD 
System  will  be  limited  to  the  tracking  and  elimination  of  these  threats  during  the  post¬ 
boost  phases  of  flight.  The  individual  system  functions  required  to  complete  an 
engagement  sequence  were  defined  in  the  requirements  analysis  and  then  documented  via 
functional  flow  diagrams  to  show  the  interrelation  of  system  functions  and  the 
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information  flow  between  them.  Figure  12  depicts  the  high-level,  notional  functional 
decomposition  of  the  ASBMD  System.  The  detailed  decomposition  of  each  individual 
system  function  is  described  in  this  section. 


Note:  Creating  functional  decomposition  diagrams  ensures  that  all  functions  in  the  system  are 
described  both  individually  and  as  a  part  of  the  overall  system  architecture.  The  hierarchical 
decomposition  model  enables  more  concise  decomposition  of  system  functions. 

Figure  12.  Notional  ASBMD  System  Decomposition 
a.  Search 

The  basic  flow  of  the  search  function  is  depicted  in  Figure  13.  The  search 
function  initiates  upon  receipt  of  a  cueing  signal  from  either  an  off-board  source  (i.e.,  an 
external,  BMDS  network  sensor)  or  the  human  operator.  The  cueing  parameters  are  then 
converted  to  radar  parameters  that  are  used  to  build  the  sector  of  space  that  will  be 
searched.  After  calculation  of  the  radar  parameters  and  required  resources,  the  system 
evaluates  the  ability  to  perform  the  requested  search  function  with  organic  resources.  At 
this  point  in  the  functional  flow,  the  system  takes  one  of  two  actions:  Either  it  determines 
that  organic  resources  are  available  and  will  carry  out  the  search  function,  or,  in  the 
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absence  of  organic  resources,  the  system  waits  for  remote  search  data  from  the  BMDS  to 
be  passed  to  the  tracking  function.  In  this  document,  this  type  of  track  data  transfer  from 
the  BMDS  will  be  referred  to  as  Launch  on  Remote  (LoR). 


o 

i 

cr 

PD 


c 


n 


3 


a 
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Note:  The  search  function  of  the  system  takes  operator  input  or  data  from  off-board  sources  and 
directs  organic  sensors  to  transmit  radio  frequency  (RF)  to  a  specific  point  or  area  in  space. 

Figure  13.  Search  Functional  Flow  Diagram 
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b.  Detect 


The  detect  function  is  shown  in  Figure  14.  The  detect  function  begins  when 
search  results  are  received  from  either  organic  or  remote  sensors.  The  results  from  the 
search  function  are  compared  against  the  current  file  of  existing  objects,  and  the  system 
determines  if  any  attributes  are  new  or  have  changed.  If  changes  or  new  objects  are 
noted,  the  location  information  is  sent  to  the  classify  function. 


Detect  Function 


Note:  The  detect  function  receives  search  results  in  the  form  of  an  RF  return  map  and  compares  it 
with  the  existing  RF  map  to  determine  if  a  new  object  exists. 

Figure  14.  Detect  Functional  Flow  Diagram 
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c.  Classify 

The  classify  function  is  shown  in  Figure  15.  The  classify  function  receives  object 
attributes  (i.e.,  altitude,  speed,  Radar  Cross  Section  (RCS),  etc.)  from  the  detect  function 
and  compares  them  with  algorithms  to  determine  if  they  represent  ballistic  or  non- 
ballistic  objects.  Upon  determination  of  the  classification  of  the  objects,  the  classify 
function  updates  the  object  attributes  including  the  identification  and  passes  the 
information  to  the  track  function. 


Classify  Function 


Note:  The  classify  function  uses  the  object  data  attributes  (velocity,  altitude,  and  bearing)  to 
determine  the  classification  of  an  object  as  a  ballistic  object. 

Figure  15.  Classify  Functional  Flow  Diagram 
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d.  Track 


The  track  function  is  shown  in  Figure  16.  The  track  function  receives  objects  from 
the  classify  function  and  computes  the  object  trajectory.  After  determining  and  updating 
the  track  attributes,  the  track  file  is  updated  and  stored.  The  updated  tracking  data  is  sent 
to  the  discrimination  function. 


The  track  function  is  key  to  the  capability  of  the  ASBMD  System  and  is 
independent  of  all  other  system  functions.  The  track  function  can  be  executed  using 
remote  or  organic  track  data.  Compilation  of  the  object  trajectory  is  used  to  determine  the 
ability  of  the  system  to  engage  the  object. 


Track  Function 


Note:  The  track  function  receives  the  output  of  the  classify  function  and  determines  additional 
attributes,  such  as  trajectory,  and  updates  the  track  fde  with  the  current  object. 

Figure  16.  Track  Functional  Flow  Diagram 
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e.  Discriminate 


The  discriminate  function  is  shown  in  Figure  17.  The  discriminate  function 
receives  track  data  from  the  track  function  and  evaluates  it,  using  predetermined 
discrimination  algorithms.  The  output  of  the  evaluations  will  be  the  identification  of  the 
number  of  lethal  objects  in  the  current  track  gate.  If  the  output  of  the  evaluation 
determines  that  there  are  more  lethal  objects  than  previously  identified,  the  discriminate 
function  will  notify  the  track  function  of  new  objects  to  be  tracked.  If  the  output  of  the 
evaluation  determines  no  new  objects,  the  discriminate  function  will  update  the  attributes 
of  the  existing  tracks  and  report  back  to  both  the  track  and  engage  functions. 


Discriminate  Function 


Note:  The  discriminate  function  receives  and  stores  track  data  and  then  evaluates  each  received 
update  against  the  unique  discrimination  algorithm.  This  ensures  proper  identification  of  the 
number  of  discrete  objects  that  are  being  tracked  and  stored. 

Figure  17.  Discriminate  Functional  Flow  Diagram 
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f.  Engage 

The  engage  function  is  shown  in  Figure  18.  The  engage  function  receives  track 
information  from  the  discrimination  function  and,  upon  operator  initiation,  will  compute 
and  disseminate  the  fire  control  solution  for  the  selected  target. 


After  operator  approval,  the  weapon  will  be  deployed,  and  the  engage  function 
will  compute  and  carry  out  the  guidance  and  KA  portion  of  the  engagement.  The  engage 
function  is  also  responsible  for  creating  and  communicating  the  current  status  of  the 
engagement  to  the  larger  BMDS. 


Engage  Function 


Note:  The  engage  function  receives  operator  or  system  commands  to  create  and  execute  a  fire 
control  solution  against  an  identified  object. 

Figure  18.  Engage  Functional  Flow  Diagram 
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Following  completion  of  the  functional  flow  diagrams,  the  team  compiled  a 
system  functional  timeline  to  assess  the  timing  requirements  for  completion  of  each 
system  function  and  the  information  flow  between  functions  throughout  the  complete 
engagement  sequence.  Figure  19  is  a  representation  of  the  information  flow  within  the 
ASBMD  System  and  a  notional  timeline  for  this  information  flow  within  the  ASBMD 
system.  The  timeline  is  based  on  the  flight  times  of  a  nominal  MRBM.  This  timeline  was 
used  to  develop  the  criteria  for  the  timing  model  employed  during  the  AoA. 


System  Functional  Timeline 
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Operator  I 


Search 


Detect 


Classify  Track 
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Compile 

Trajectory 


Update 
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\ssessmen' 


Re-Engage 


60  Sec 


Total 

Nominal  Missile 
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Note:  Functional  timeline  analysis  ensures  that  each  function  is  allotted  a  specific  portion  of  the 
timeline  while  maintaining  the  overall  system  timeline.  Detailed  functional  interaction  as  depicted 
ensures  a  consistent  system  flow  of  information.  This  timeline  was  used  to  develop  the  criteria  for 
the  timing  model  employed  during  the  AoA. 

Figure  19.  ASBMD  Information  Flow  and  Functional  Timeline  Diagram 
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D.  SYSTEMS  ANALYSIS  SUMMARY 


As  described  in  the  preceding  sections  of  this  chapter,  the  team  created  a  number 
of  system  analysis  artifacts  for  the  purpose  of  defining  and  analyzing  conceptual  system 
architectures  that  could  address  the  problem  statement.  Stakeholder  inputs  were  solicited 
for  the  purpose  of  deriving  high-level  system  requirements.  These  requirements  were 
decomposed  during  FSA.  The  output  of  this  functional  decomposition  was  a  detailed  set 
of  functional  requirements  and  engagement  timing  criteria  that  were  applied  in  the  AoA, 
described  in  Chapter  III. 
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III.  ANALYSIS  OF  ALTERNATIVES 


A.  OVERVIEW 

Analysis  of  Alternatives  (AoA),  as  defined  by  Ullman,  (2006),  is  the  analytical 
comparison  of  multiple  alternatives  to  be  completed  before  committing  resources  to  a 
designated  project.  DoDI  5000.02  (2008,  December  8)  establishes  the  basis  for 
developing  an  AoA  and  defines  the  objectives  of  the  AoA.  The  practice  of  comparing 
multiple  alternative  solutions  has  long  been  a  part  of  engineering  practices  in  the  DoD. 
There  is,  however,  a  natural  human  tendency  to  propose  a  single  alternative  for 
investigation  or  development  and  justify  this  option  rather  than  compare  multiple  options 
with  the  goal  of  choosing  the  best  fit.  Thus,  government  agencies,  such  as  DoD,  have 
found  it  necessary  to  encourage  those  proposing  projects  to  use  an  AoA  structure  to 
properly  evaluate  their  options.  The  ASBMD  team  has  conducted  an  AoA  using  a 
modified  process  similar  to  that  used  in  many  DoD  agencies.  This  chapter  details  the 
modified  process  that  was  selected. 

The  objective  of  this  AoA  was  to  answer  specific  questions  that  were  required  to 
ensure  that  the  chosen  system  met  the  requirements  of  the  project.  The  outcome  of  the 
AoA  is  a  single,  recommended  architecture  that  meets  the  functional  requirements, 
schedule,  and  cost  constraints  of  the  system.  Although  the  outcome  is  a  single  core 
system,  the  recommended  architecture  includes  multiple  elements  or  systems  that  will  be 
integrated  into  a  single  architecture  to  combat  the  identified  threat  group.  The  details  of 
how  the  system  is  integrated  will  be  explained  in  Chapter  IV. 

The  purpose  of  the  AoA  for  this  project  was  to  answer  the  following  questions: 

1 .  What  is  the  most  cost-effective,  sea-based  alternative  for  defending  CSGs 
against  the  emerging  ASBM  threat  group?  (This  refers  to  the  most 
cost-effective  approach  that  meets  the  key  functional  requirements  identified 
during  the  CONOPS  and  functional  analysis  portion  of  the  project.) 
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2.  Which  alternative  introduces  the  least  amount  of  risk  in  all  cost,  schedule,  and 
performance  aspects? 

3.  Which  alternative  allows  for  the  shortest  fielding  and  deployment  schedule? 
(This  addresses  the  emergent  need  aspect  of  the  problem.) 

B.  PROCESS 

The  ASBMD  team  created  a  modified  analysis  technique,  as  depicted  in 
Figure  20.  As  the  figure  shows,  the  process  is  iterative,  and  there  is  a  natural  increase  in 
detailed  analysis  artifacts  and  their  fidelity,  as  the  process  flows  up  the  pyramid.  The  key 
to  the  process  is  the  development  of  a  well  defined  set  of  baseline  documents  at  the  start 
of  the  analysis.  Baseline  documents  in  this  case  are  the  documents  that  the  team  created 
during  the  system  functional  analysis  portion  of  the  product;  they  consist  of  the 
CONOPS,  ICD,  DRMs,  and  functional  flow  diagrams.  Although  the  key  is  to  maintain 
stable  baseline  documents,  the  process  is  designed  to  have  feedback  loops  that  drive 
updates  to  the  preceding  steps  as  additional  details  are  defined.  For  example,  as  the  team 
identified  the  key  functional  attributes  (KFAs),  the  analysis  demonstrated  the  need  to  add 
another  level  of  detail  to  the  requirements  that  were  developed  during  the  CONOPS  and 
ICD  phases  of  the  project.  These  modifications  are  not  functional  changes  to  the 
requirements,  but  they  ensure  that  the  attributes  being  developed  and  analyzed  are  correct 
and  consistent  with  the  scope  of  the  project.  Updating  requirements  as  the  technical 
assessment  progresses  ensures  that  traceability  is  maintained  throughout  the  project.  Each 
step  in  the  process  will  be  detailed  in  the  following  sections  of  this  chapter.  The  outcome 
of  the  AoA  is  a  detailed  set  of  analysis  artifacts  that  were  applied  in  the  concept 
architecture  and  integration  portions  of  the  project. 
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Note:  The  AoA  process  designed  by  the  ASBMD  team  ensured  that  a  complete  and  consistent 
concept  architecture  was  created  that  was  reinforced  by  detailed  analysis  artifacts.  The  ASBMD 
team  used  the  AoA  process  to  ensure  that  traceability  was  thorough  and  complete  through  all  of 
the  analyses  and  artifacts. 

Figure  20.  ASBMD  Analysis  of  Alternatives  Process 
1.  Requirements  Refinement 

The  success  of  this  process  depends  on  the  early  definition  and  refinement  of  the 
requirements  and  functions  of  the  system.  Since  the  requirements  and  their  associated 
documents  (CONOPS,  ICD,  etc.)  are  the  basis  for  the  analysis  and  the  ultimate  selection 
of  an  alternative,  it  is  imperative  that  they  are  made  clear  and  concise  as  early  as  possible 
in  the  analysis  process.  Requirements  changes  are  inevitable;  therefore,  a  clear  line  of 
feedback  (as  depicted  in  Figure  20)  to  all  parent  documents  is  key  to  ensuring  that  the 
engineering  of  the  system  is  consistent  and  correct.  The  AoA  process  began  with  a  set  of 
high-level  requirements  that  were  derived  from  the  CONOPS  and  ICD.  Each  requirement 
is  associated  to  the  key  functions  that  were  identified  in  Chapter  II.  Verification  that  the 
derived  requirements  remained  aligned  with  the  key  functions  continued  throughout  the 
AoA.  As  each  step  of  the  process  was  started  and  subsequently  completed,  the  engineer 
assigned  to  a  specific  function  assessed  the  requirements  and  associated  documentation  to 
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ensure  that  they  were  still  correct,  complete,  and  concise.  Although  the  process  is 
continuous,  the  number  of  modifications  and  clarifications  to  the  requirements  reduces 
considerably  as  the  assessment  advances  up  the  levels  of  the  pyramid.  This  is  attributable 
to  each  step  building  on  the  analysis  performed  and  the  artifacts  produced  for  the 
preceding  steps.  The  majority  of  the  requirements  changes  occurred  during  the  creation 
of  KFAs;  this  is  due  to  the  analysis  having  determined  the  need  for  additional 
requirements  details  to  support  the  functional  requirements  of  the  system.  A  depiction  of 
this  update  process  is  shown  in  Figure  21.  This  represents  the  iterative  refinement  aspect 
of  the  requirements  development  process  originally  depicted  in  Figure  7. 


Note:  Updates  were  applied  to  system  requirements  and  associated  documentation  as  needed 
throughout  the  analysis  process  to  ensure  correctness  and  completeness. 

Figure  21.  Process  Flow  for  Requirements  Refinement  and  Documentation  Updates 
2.  Key  Functional  Attributes 

The  next  step  in  the  process  was  the  creation  of  KFAs.  KFAs  are  the  system 
attributes  that  are  required  to  effectively  evaluate  system  performance  against  the 
requirements  that  were  identified  during  the  ICD  phase  that  were  further  detailed  during 
the  requirements  refinement  step.  These  are  the  system  attributes  that  must  be  analyzed  to 
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determine  the  functional  capabilities  of  candidate  systems  that  are  chosen  for  assessment 
during  the  AoA.  The  KFAs  that  the  team  identified  were  those  attributes  that,  when 
analyzed,  would  provide  a  clear  and  objective  view  of  the  capabilities  of  the  candidate 
systems.  For  example,  for  the  search  function,  the  team  identified  the  scan  rate,  search 
volume,  and  angular  resolution  as  the  functional  attributes  that  would  be  used  to  evaluate 
each  candidate  system. 

The  ASBMD  team  identified  KFAs  for  each  functional  area  depicted  in  Table  7. 
As  previously  described,  the  feedback  loop  from  each  step  in  the  process  to  the  preceding 
steps  ensures  a  consistent  flow  and  commonality  across  all  functions  and  requirements. 
During  the  analysis  and  creation  of  the  KFAs,  the  team  identified  multiple  KFAs  that 
demonstrated  a  need  for  the  requirements  to  be  refined.  The  requirements  refinement 
ensured  sufficient  detail  to  support  the  KFAs  that  were  identified. 

Table  7.  Key  Functional  Attributes 

Note:  The  ASBMD  team  created  KFAs  to  identify  the  attributes  that,  when  analyzed,  would 
provide  detailed  analysis  artifacts  to  assist  in  the  decision  of  the  final  elements  or  systems  that 
would  comprise  the  concept  architecture.  KFA  development  was  an  important  factor  in  the  further 
refinement  of  system  requirements  and  timing  analysis.  KFAs  were  weighted  by  stakeholder 
inputs  and  became  criteria  for  system  evaluation  during  the  AoA. 


Analysis  Area 

Recommended  Attribute  Analysis 

Search 

Search  Rate  (Scan  Rate) 

Search  Volume  Capabilities 

Range 

Angular  Resolution 

Detection 

Signal-to-Noise  Ratio 

False  Alarm  Rate 

Probability  of  Detection  (Adjusting  Target  and  Environmental  Attributes) 

Radar  Range  Calculation  for  Maximum  Detection  Range 

Tracking 

PRF  and  Tracking  Errors 

Effective  Aperture  and  Resolution  Calculations 

Effects  of  Tracking  Ranges  Given  Tracking  and  Turning  Gate  Changes 

Transition-to-Track  Timeline  Analysis 

Intercept  Variants 

General  Systems  Capability  Analysis 

Kill  Timeline  Analysis  by  Varying  Range 

Maximum  Effective  Ranges 
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3.  System  Attribute  Analysis 

The  system  attribute  analysis  step  of  the  AoA  process  is  the  point  where  the  team 
began  the  identification  of  the  analysis  artifacts  that  would  be  used  to  evaluate  each  KFA 
identified  in  the  earlier  steps  of  the  AoA  process.  Analysis  artifacts  identified  by  the  team 
included  tables,  graphs,  and  charts  that  would  provide  clear,  easily  understood 
documentation  to  assist  in  the  final  architecture  decision.  After  creation  of  the  KFAs,  the 
team  defined  a  list  of  candidate  artifacts  that  were  used  to  perform  an  analytical 
comparison  of  the  candidate  systems  that  would  be  defined  in  the  successive  steps  of  the 
process.  For  example,  as  depicted  in  Figure  22,  to  evaluate  the  search  function  of  the 
candidate  systems,  the  team  created  artifacts  to  evaluate  maximum  detection  range  vs. 
RCS  and  minimal  detectable  signal  vs.  range.  These  analysis  artifacts  were  used  to  assist 
in  the  one-to-one  comparison  of  each  concept  architecture  in  the  system  comparison 
phase.  Additional  system  attribute  analysis  sheets  were  created  for  each  system  function; 
a  compilation  of  these  analysis  sheets  is  provided  in  Appendix  E. 
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Note:  System  attribute  analysis  provides  the  detailed  analysis  technique  that  the  team  used  to 
evaluate  each  candidate  element  or  system.  The  analysis  artifacts  were  used  to  assist  in  the  one-to- 
one  comparison  of  each  concept  architecture. 

Figure  22.  System  Attribute  Analysis  Sheets  Example 
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4.  System  Comparison 

Following  creation  of  the  KFAs  and  system  analysis  sheets,  the  team  defined  a  list 
of  candidate  elements  and/or  systems  for  each  defined  function.  This  list  was  derived 
from  the  documents  created  during  the  initial  system  research  and  analysis  phases  of  the 
project,  in  conjunction  with  the  operational  experience  of  each  team  member.  Although 
the  list  may  appear  somewhat  limited,  the  team  tried  to  bound  the  size  of  the  list  to 
contain  only  those  options  that  were  feasible  and  met  the  functional,  cost,  and  schedule 
requirements  of  the  project.  Each  team  member  then  performed  a  detailed  analysis  of 
each  candidate  system  to  gather  the  required  information  to  evaluate  the  KFAs.  To  ensure 
that  the  project  was  kept  unclassified,  the  detailed  analysis  and  information  gathering 
included  only  information  that  was  readily  available  via  public  domain  sources.  After 
data  were  gathered,  each  team  member  created  specific  system  analysis  sheets  for  each 
candidate  system.  Creation  and  evaluation  of  the  system  analysis  sheets  allowed  the  team 
to  rank  each  system  according  to  how  well  it  performed  its  function.  The  team  was  also 
able  to  identify  pros  and  cons  for  each  system  to  assist  in  the  ranking.  After  a  detailed 
analysis  was  performed,  the  data  were  combined  into  a  single  system  comparison 
spreadsheet,  as  shown  in  Table  8.  The  outcome  of  this  step  is  a  consolidated  list  of 
elements  and/or  systems  that  were  evaluated  on  their  ability  to  meet  the  performance 
requirements,  as  well  as  a  one-to-one  comparison  based  solely  on  how  each  system 
performed  against  the  KFAs.  A  full  system-of-systems  comparison  occurred  later  in  the 
process  and  considered  other  aspects  of  the  project,  such  as  risk  assessment  and 
cost/schedule  requirements. 
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Table  8.  System  Comparison 


Note:  The  team  used  system  comparison  sheets  to  perform  comparisons  of  each  system  identified 
to  meet  the  associated  requirements.  The  sheets  displayed  the  functional  and  operational  pros  and 
cons  for  each  system,  which  the  team  found  useful  in  determining  the  final  architecture. 


Function  Name  (Search/Detection) 

Options 

Performance  Parameters 

Requirements 

Pros  /  Cons 

Max 

Range/ 

Accuracy 

Max 

Power 

Ae 

(Effective 

Aperture 

Size) 

Smin 

SPY-1  B(D) 

*  1460  KM 

3  MW 

20  mA2 

-13  dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than 

750  km  in  less  than  2  seconds, 
when  cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Mature,  proven  system  capability 

Con:  Shorter  maximum  range  limits  the 
maneuverability  options  of  the  Fleet 
Con:  Heavily  reliant  on  intelligence  data  to 
allow  for  resource  focusing 

SPY- 3 

**  2527  KM 

4.5  MW 

23  mA2 

-23  dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than 

750  km  in  less  than  2  seconds, 
when  cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Greater  search  range  and  accuracy 
capabilities  than  the  SPY-1 

Pro:  Greater  peak  power  and  Ae  size 
allows  for  search  and  detection  of 
smaller  RCS 

Con:  Unproven  system  that  is  still  under 
development 

Con:  Power  usage  to  excite  radar  elements 
exceeds  that  of  current  ship 
capabilities 

Con:  Unable  to  uplink  with  current  weapon 
inventory 

Cobra  Judy 

**  2681  KM 

7  MW 

26.4  mA2 

-20  dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than 

750  km  in  less  than  2  seconds, 
when  cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Greatly  increases  search  and 
detection  ranges 

Pro:  Allows  greater  operational 
maneuverability 

Con:  Large  power  consumption 
requirements 

Con:  Unable  to  control  current  weapons 
Con:  Too  large  to  fit  onto  current 
operational  naval  vessels 

GBR-P 

**  3297  KM 

8  MW 

20.4  mA2 

-23  dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than 

750  km  in  less  than  2  seconds, 
when  cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Increased  search  and  detection 
ranges 

Pro:  Increases  operational  capability  of 
fleet 

Con:  Power  consumption  is  too  great 

Con:  Weight  and  size  are  restrictive 

Con:  RCS  signature  much  too  large  for 
naval  vessel 

Con:  No  weapon  control  capability 

All  calculations  assume  30  degree  search  sector. 

*  Derived  from  Aegis  BMD  briefing. 

**  See  specific  Radar  Calculation  Sheets. 
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5.  Model  Creation 


After  candidate  systems  were  identified  and  a  detailed  analysis  was  performed  for 
each  system,  the  team  created  high-level  system  models  using  the  Arena  modeling  tool 
set.  Although  this  was  not  the  only  modeling  tool  used  during  the  analysis  process,  the 
team  chose  Arena  as  the  primary  modeling  tool  due  to  the  team's  familiarity  with  the 
program  and  the  its  capabilities.  Arena  is  a  useful  tool  when  modeling  both  high-level 
systems  and  subsystems  from  a  timing  perspective.  It  allows  easy  manipulation  of  the  key 
timing  drivers  identified  by  the  user.  This  was  important  to  the  team  because  system 
timing  was  recognized  early  in  the  analysis  process  as  a  critical  dependency  in  this 
assessment.  The  graphical  interface  provides  ease  in  the  creation  of  metrics  and  charts 
that  measure  and  monitor  KSAs.  Early  in  the  project,  the  team  conducted  and 
documented  a  modeling  proficiency  demonstration  using  Arena.  The  purpose  of  this 
exercise  was  to  illustrate  the  team's  ability  to  use  Arena  to  generate  a  high-level  system 
simulation  of  BMD  functions  over  the  course  of  a  ballistic  missile  threat  flight  from 
detection  to  intercept. 

The  modeling  output  examples  described  below  are  examples  of  the  functional 
modeling  analysis  conducted  by  the  team.  Functional  modeling  was  the  process  of 
creating  a  model  that  contained  each  system  function  that  was  identified  during  the 
functional  decomposition  phase.  As  the  project  progressed  and  the  team  identified 
specific  candidate  systems/elements  that  could  perform  the  identified  functions,  the 
system-specific  timing  values  and  behaviors  of  candidate  systems  were  inserted  into  the 
model.  Because  each  candidate  system  was  required  to  fulfill  the  identified  system 
functions,  the  team  did  not  create  a  separate  model  for  each  candidate  system.  However, 
the  team  used  the  model  to  prove  or  disapprove  any  assumptions  that  the  team  had  for 
each  candidate  system. 
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Two  separate  levels  of  Arena  models  were  created  for  this  step  of  the  process. 
These  models  are  shown  in  detail  in  Appendix  E.  The  gross  system  model  depicted  in 
Figure  23  was  used  primarily  to  evaluate  system  timing  and  to  identify  major 
impediments  to  system  integration. 


Note:  The  gross  system  model  is  used  to  identify  the  ability  of  the  concept  architecture  to  meet  the 
overall  system  timing  constraints.  This  model  assisted  in  understanding  the  ability  to  integrate 
each  element  or  system  into  a  system  of  systems. 

Figure  23.  Gross  System  Model 

After  timeline  analysis  was  performed  using  the  gross  model  shown  in  Figure  23, 
the  team  created  multiple  sub-models  to  assist  in  the  evaluation  of  the  candidate  systems. 
Each  candidate  system  was  evaluated  individually,  using  the  model  depicted  in  Figure  24. 
This  allowed  the  team  to  understand  the  dependencies  created  as  each  system  was 
integrated.  The  models  were  used  to  ensure  that  the  systems,  when  integrated,  met  the 
overall  performance  requirements  for  the  system  of  systems  under  varying  conditions. 

The  team  modified  attributes,  such  as  RCS,  range,  probability  of  kill  (PK),  probability  of 
detection  (Pd),  and  flight  times,  to  ensure  that  the  systems  still  met  the  overall  system 
requirements.  Subsequent  sections  of  this  document  will  describe  the  steps  taken  to 
narrow  the  candidate  systems  using  interoperability  as  one  of  the  main  requirements. 
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Note:  The  detailed  system  model  is  used  to  identify  and  understand  the  dependencies  created  as 
each  system  was  integrated  to  create  a  system  of  systems  solution. 

Figure  24.  Detailed  System  Model 

When  the  candidate  architectures  were  narrowed  to  two,  the  model  depicted  in 
Figure  25  was  employed  to  help  ensure  that  the  selected  solution  met  the  overall  system 
requirements  when  integrated  at  the  system-of-systems  level.  The  outcome  of  the  model 
analysis  provided  additional  details  that  were  used  to  assist  in  the  final  architecture 
decision.  The  results  of  the  model  analysis  were  used  to  generate  the  system-of-systems 
analysis  and  are  described  in  section  C  below. 
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Note:  Sub-models  were  used  to  ensure  that  the  chosen  elements  or  systems  met  the  timing 
requirements  of  the  overall  system.  The  sub-models  also  assisted  in  identifying  the  key 
interactions  required  to  integrate  into  a  systems-of-systems  architecture. 

Figure  25.  Functional  Sub-Model  Breakout  Example 
C.  SYSTEM-OF-SYSTEMS  ANALYSIS 

As  previously  discussed,  the  AoA  process  covered  only  the  analysis  of  the 
individual  candidate  elements  and/or  systems;  the  system-of-systems  analysis  portion  of 
the  project  is  where  the  team  performed  the  detailed  comparison  of  each  of  the  candidate 
architectures  integrated  at  the  system-of-systems  level.  This  process  examined  each 
system’s  ability  to  meet  not  only  the  performance  requirements,  but  also  its  ability  to 
meet  the  identified  cost  and  schedule  constraints.  The  outcome  of  this  analysis  was 
multiple  system  configurations  that  could  meet  the  identified  functional  requirements. 
The  configurations  were  ranked  according  to  the  capability  to  be  deployed  quickly  and 
cost  effectively  and  were  compiled  into  a  ranked  list.  This  list  illustrates  that  one  solution 
can  be  deployed  quickly,  while  continued  development  of  an  alternate  solution  can 
introduce  greater  capability  at  a  later  time. 

1.  Concept  Architecture  Analysis 

The  next  step  was  the  formulation  of  end-to-end,  system-of-systems  concept 
architectures  that  could  be  used  to  combat  the  ASBM  threat.  The  team  used  the  analysis 
artifacts  that  were  created  during  the  AoA  process  described  above  to  identify  the  best  fit 
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solutions  for  each  function.  After  determining  the  system  or  element  that  was  the  best  fit 
for  each  function,  the  team  used  a  mixture  of  engineering  analysis,  experience,  and 
discussion  to  derive  multiple  combinations  of  elements  that  could  be  integrated  into  a 
coherent  system  of  systems.  The  team  used  the  models  described  in  section  B  of  this 
chapter  to  ensure  that,  when  integrated,  each  candidate  architecture  could  meet  the 
overall  timing  defined  in  the  system  requirements. 

The  team  then  created  the  concept  architecture  analysis  comparison  sheet, 
depicted  in  Figure  26,  to  document  the  elements/systems  that  were  integrated  into 
candidate  architectures. 
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Notes: 

1 .  System  configurations  were  not  evaluated  if  they  were  ruled  out  in  earlier  processes  or  were  immediately  deemed  not  interoperable 
(system  comparison,  cost  analysis,  stakeholder  discussions,  etc.). 

2.  Fire  control  and  weapons  would  be  shipboard  only  due  to  range  from  land  sensors. 

3.  No  tail  chase  scenarios  were  identified;  therefore,  this  requirement  was  not  driven  to  the  system  architectures. 

4.  External  sensors  are  defined  as  BMDS  networked  sensors,  to  include  AN/TPY-2,  additional  AN/SPY-1  assets,  airborne  sensors,  and 
Overhead  Persistent  Infrared  (OPIR)  assets. 

5.  Launch  on  Remote  (LoR)  will  be  the  base  scenario  when  external  sensors  are  available. 

6.  Specified  Fire  Control  Systems  are  hull-specific  and  are  not  interchangeable  (i.e.,  Aegis  =  DDG  51  class  hull,  etc.). 


Note:  Architecture  comparison  sheets  document  each  of  the  elements  or  systems  that  could  be 
combined  to  meet  the  overall  requirements  of  the  ASBMD  system. 

Figure  26.  Concept  Architecture  Analysis  Comparison  Sheet 
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The  six  elements/systems  are  defined  as  follows: 


Network  Sensors: 

•  This  term  refers  to  the  sensors  that  are  already  included  in  the  BMDS 
network  (AN/TPY-2,  AN/SPY- 1,  Upgraded  Early  Warning  Radar 
(UEWR),  and  Overhead  Persistent  Infrared  (OPIR)). 

Interoperability: 

•  Command  and  Control  Battle  Management  and  Communications 
(C2BMC)  is  the  core  interoperability  and  element  coordination 
architecture  for  the  BMDS. 

•  Link  16  is  the  high  speed,  L-Band  digital  data  link  currently  in  service 
throughout  U.S.  Navy  systems  and  networks. 

•  The  Cooperative  Engagement  Capability-Distributed  (CEC-D)  system  is 
an  updated  Cooperative  Engagement  Capability  (CEC)  system  that  adds 
the  capability  to  process  space  tracks,  including  updated  algorithms  to 
allow  processing  of  tracks  with  very  large  velocities.  The  CEC-D  system 
has  an  initial  operational  capability  (IOC)  of  early  2010. 

Shipboard  Fire  Control  Systems: 

•  AN/SPY- 1  is  the  is  the  primary  air  and  surface  radar  for  the  Aegis  Combat 
System  installed  in  the  USS  Ticonderoga  (CG  47)  and  USS  Arleigh  Burke 
(Guided  Missile  Destroyer  (DDG)  51)-class  warships.  It  is  a 
multifunction,  phased-array  radar  capable  of  search,  automatic  detection, 
transition  to  track,  tracking  of  air  and  surface  targets,  and  missile 
engagement  support. 

•  AN/SPY-3  is  an  active,  phased-array  X-band  radar  designed  to  meet  all 
horizon  search  and  fire  control  requirements  for  the  next  generation  of 
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U.S.  Navy  ships.  It  supports  new  ship  design  requirements  for  reduced 
RCS,  significantly  reduced  manning  requirements,  and  total  ownership 
cost  reduction.  The  multifunction  radar  is  designed  to  assume  the 
functions  of  five  separate  radar  systems  that  are  currently  in  service. 

SPY-3  is  scheduled  to  IOC  in  2012. 

•  Ground-Based  Radar-Prototype  (GBR-P)  is  an  X-band  phased  array  radar 
and  fire  control  sensor  that  provides  precision  discrimination  and 
interceptor  fire  control  support  capability  to  the  BMDS.  There  is  currently 
only  one  GBR-P  installation,  located  at  Kwajalein  Atoll.  While  the  full 
ground-based  concept  would  not  be  suitable  for  this  assessment,  what  was 
considered  is  a  modernized,  shipboard-scale  X-band  phased  array  radar 
that  is  capable  of  providing  the  same  in-flight  interceptor  communications 
system  (IFICS)  and  in-flight  target  update  (IFTU)  support  featured  in  the 
GBR-P  system. 

Data  Link: 

•  S-Band  Data  Link  is  used  by  the  AN/SPY- 1  radar  for  acquisition  and 
midcourse  communication  with  Standard  and  Evolved  Sea  Sparrow 
Missile  variants.  The  S-Band  Data  Link  is  primarily  used  by  legacy  Aegis 
systems. 

•  X-Band  Data  Link  is  used  by  the  AN/SPY-3  radar  for  acquisition  and 
midcourse  communication  with  Standard  and  Evolved  Sea  Sparrow 
Missile  variants.  The  X-Band  Data  Link  is  the  preferred  ownship  missile 
communication  mechanism  for  systems  being  designed  for  use  in  a  littoral 
environment  due  to  its  improved  clutter  rejection  and  anti-jamming 
capability. 
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Launcher  Mechanism: 


•  MK-41  Vertical  Launching  System  (VLS)  is  the  currently  fielded, 
canister-based,  fixed  shipboard  launcher.  It  is  capable  of  firing  a  variety  of 
ordnance  items  and,  if  appropriately  configured,  is  able  to  simultaneously 
support  multiple  missions,  including  both  Anti  Air  Warfare  (AAW)  and 
BMD. 

•  MK-57  VLS  is  an  open-architecture-compliant  launcher  developed  for  the 
DDG  1000  platform.  It  is  designed  to  accommodate  existing  VLS 
encanistered  missiles  but  provides  for  the  growth  in  volume  and  weight 
expected  for  future  missile  systems.  It  is  scheduled  to  IOC  in  2012. 

•  Rail  Gun  is  a  weapon  system  that  moves  a  projectile  along  a  pair  of  metal 
rails  using  two  sliding  or  rolling  contacts.  The  contacts  permit  a  large 
electric  current  to  pass  through  the  projectile,  which  interacts  with  the 
magnetic  field  around  each  rail  to  accelerate  the  projectile.  Although  the 
U.S.  Navy  has  tested  a  rail  gun  that  is  capable  of  accelerating  a  3.2 
kilogram  (kg)  projectile  to  greater  than  Mach  7,  no  Navy  platform  can 
currently  support  the  space  and  infrastructure  needs  (i.e.,  provide  power 
and  cooling)  that  would  allow  further  development  and  deployment  of  this 
functionality. 

•  Laser  weapons  system  is  a  megawatt-class  chemical  oxygen  iodine  laser 
(COIL)  that  could  be  modified  for  integration  in  U.S.  Navy  ships.  In  BMD 
applications,  this  type  of  laser  is  primarily  designed  to  destroy  ballistic 
threats  in  their  boost  phase.  A  shipboard  laser  weapon  system  is  not 
feasible  for  BMD  scenarios  due  to  proximity  to  the  launch  site  that  would 
be  required  for  a  boost  phase  intercept;  however,  MDA  has  developed  and 
tested  the  Airborne  Laser  (ABL)  platform  for  boost  phase  intercept 
capability. 


56 


Interceptor: 


•  SM-3  is  the  U.S.  Navy’s  midcourse  ballistic  missile  interceptor.  The 
certified  SM-3  Block  IA  is  currently  in  service.  SM-3  Block  IB,  which 
features  enhanced  capabilities  and  would  be  the  desired  candidate  for 
consideration  in  the  ASBMD  scenario,  is  scheduled  for  IOC  in  201 1.  The 
Block  IB  design  includes  an  advanced,  two-color,  infrared  seeker  for 
enhanced  discrimination  capabilities.  Its  Throttleable  Divert  and  Attitude 
Control  System  (TDACS)  will  provide  the  kill  vehicle  with  greater  agility, 
which  is  advantageous  for  use  against  maneuvering  threats. 

•  Rail  Gun  Mod  1  Ballistic  Round  is  a  lightweight  projectile  designed  for 
use  with  the  developmental  rail  gun  concept. 

Although  many  systems  could  have  been  analyzed,  the  team  included  only  those 
that  met  the  functional  capabilities  and  performance  parameters  identified  during  the 
functional  analysis  and  system  comparison  phase.  This  resulted  in  the  creation  of 
candidate  architectures  that  were  more  feasible  and  could  potentially  meet  the 
performance  criteria  and  system  requirements,  including  cost  and  schedule  constraints. 

2.  Selection  of  Concept  Architecture  Options  for  Evaluation 

During  this  portion  of  the  process,  the  team  performed  detailed  analyses  of  each 
candidate  architecture  that  was  identified  during  the  earlier  steps  of  the  assessment.  The 
detailed  analysis  included  identification  of  the  pros  and  cons  for  each  architecture.  The 
pros  and  cons  included  both  technical  and  programmatic  issues  and  were  identified  using 
available  literature  and  working-level  knowledge  of  the  team  members.  After  detailing 
and  analyzing  each  candidate  architecture,  the  team  narrowed  the  concept  architectures 
based  on  all  artifacts  that  had  been  created  up  to  that  point  in  the  process.  Those  artifacts 
included  the  KFAs,  models,  systems  attribute  sheets,  and  system  requirements.  Based  on 
system  availability,  ability  of  the  systems  to  meet  stakeholder  requirements,  and 
performance  of  the  systems  in  the  models,  the  team  ranked  the  concept  architectures  and 
provided  detailed  rationale  to  justify  why  each  concept  architecture  option  was  or  was  not 
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chosen.  The  ranking  of  the  top  concept  architecture  options  and  the  associated  rationale 
for  each  are  depicted  in  Table  9.  Next,  the  team  created  the  architecture  diagrams  for  the 
top  three  ranked  choices  to  provide  a  graphical  representation  of  each  option.  The 
diagrams  are  shown  in  Figures  27,  28,  and  29;  these  contain  the  pros  and  cons  for  each 
system. 
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Table  9.  Ranking  of  Concept  Architecture  Options 

Note:  Ranking  of  the  systems  assists  in  focusing  the  detailed  analysis  and  artifact  creation  to  only 
those  options  that  meet  the  high-level  requirements,  cost,  and  schedule  constraints.  The  options 
labeled  “not  ranked”  (NR)  were  eliminated  due  to  their  inability  to  meet  one  or  more  of  these 
constraints. 


Option 

# 

Architecture  Descriptor 

Evaluation 

Priority/Rank 

Rationale 

1 

Zumwalt  Fire  Control  with 
Updated  Discrimination  and 
Tracking  Algorithms 

3 

•  Zumwalt  IOC  is  -2014. 

•  Option  requires  changes  to  SPY-3 
and  Combat  Systems.  (Near  field 
range  testing  required.) 

la 

Zumwalt  Fire  Control  with 
Updated  Discrimination  and 
Tracking  Algorithms,  Weapons 
Control  Changes  for  Rail  Gun 

NR 

•  Zumwalt  IOC  is -2014. 

•  Very  high  development,  integration, 
and  testing  costs 

•  Schedule  constraints 

lb 

Zumwalt  Fire  Control 
integrated  with  SPY-1  Radar 
guidance  and  control 

4 

•  Zumwalt  IOC  is  -2014. 

•  Very  high  development,  integration, 
and  testing  costs  with  integrating 
new  radar  into  existing  Fire  Control 

•  Schedule  constraints 

1c 

Zumwalt  Fire  Control  with 
Updated  Discrimination  and 
Tracking  Algorithms,  Weapons 
Control  Changes  for  Laser 
System 

NR 

•  Zumwalt  IOC  is -2014. 

•  Laser  System  IOC  is  beyond  2015. 

•  Very  high  development,  integration, 
and  testing  cost 

•  Very  high  risk  of 
technology/capability  not  being 
sufficient 

2 

Modified  Aegis  Fire  Control 
with  updated  Discrimination 
and  Tracking  Algorithm 

1 

•  Quick  development  and  deployment 
with  minimal  integration  and  testing 
cost 

•  Minimal  schedule  impact. 

•  Availability  could  meet  need  dates. 

2a 

Modified  Aegis  Fire  Control 
integrated  with  SPY-3  Radar 
for  guidance  and  control 

2 

•  Platform  cannot  support  the  power 
and  cooling  requirements  of  SPY-3. 

•  Integration  and  testing  timeline  does 
not  support  need  dates. 

3 

Modified  Zumwalt  Fire  Control 
integrated  with  Modernized 
GBR-P  System  for  guidance 
and  control 

NR 

•  Option  involves  a  very  long  and 
costly  development,  integration,  and 
testing  timeline  that  would  not  meet 
need  dates. 

•  Complex  integration  effort  required 
to  use  GBR-P  for  ordnance  control. 

3a 

Modified  Aegis  Fire  Control 
integrated  with  Modernized 
GBR-P  System  for  guidance 
and  control 

NR 

•  Option  involves  a  very  long  and 
costly  development,  integration,  and 
testing  timeline  that  would  not  meet 
need  dates. 

•  Platform  cannot  meet  the  cooling 
and  power  requirements  of  the 

GBR-P  System. 
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Option  1  Concept  Architecture 


*  Positives 

o  Increased  detection  and  tracking 
ranges 


-  Negatives 

o  Cannot  meet  cost  and  schedule 
o  IOC  of  DBR  Radar  does  not  support 
urgent  requirement 

o  Cost  and  schedule  required  to  retest 
fire  control  chain  is  excessive 
o  Missile  uplink  has  not  been  proven 


External 

Sensors 


MK57VLS 


Tj 


SM-3  Block  IB 


Zu  m  wait  Fire  Con  tro  I 


NGC2P 


WCE 


!_►  C2I 


DBR  Radar 


ux 


Bi  nd  Up/On 
is*  ite  Datalink 


Note:  The  Option  1  concept  architecture  depicts  the  integrated  solution  using  the  Zumwalt  Combat 
System  as  the  baseline  configuration.  This  figure  identifies  the  pros  and  cons  for  this  architecture. 

Figure  27.  Option  1  Concept  Architecture 
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Note:  The  Option  2  concept  architecture  depicts  the  integrated  solution  using  the  Aegis  Combat 
System  as  the  baseline  configuration.  This  figure  identifies  the  pros  and  cons  for  this  architecture. 

Figure  28.  Option  2  Concept  Architecture 
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Note:  The  Option  2a  concept  architecture  depicts  the  integrated  solution  using  a  hybrid  Zumwalt 
and  Aegis  Combat  System  as  the  baseline  configuration.  This  figure  identifies  the  pros  and  cons 
for  this  architecture. 

Figure  29.  Option  2a  Concept  Architecture 
3.  One-to-One  Comparison  of  Ranked  Concepts 

The  final  step  of  the  AoA  portion  of  the  project  was  to  compare  the  ranked 
concept  architectures  to  ensure  a  complete  understanding  of  the  magnitude  of  the  impacts 
associated  with  employment  of  the  concept  architectures.  For  example,  some  of  the 
architectures  would  result  in  software-only  changes,  while  others  would  result  in 
hardware  and  software  changes  that  could  impact  the  ability  to  meet  the  schedule 
constraints  of  the  project.  The  comparison  analysis  resulted  in  development  of  a 
capabilities  and  limitations  sheet,  shown  in  Table  10.  Each  concept  option  would  provide 
the  required  capability  to  combat  the  threat  identified  in  the  problem  statement,  but  the 
limitations  of  implementing  some  concept  architectures  could  result  in  integration 
challenges  that  would  render  the  entire  BMDS  system  less  agile  or  capable.  The  next 
activity  that  the  team  undertook  during  this  step  was  conduct  of  a  performance  and 
capability  comparison  assessment  summary  for  the  ranked  concept  architectures.  This  is  a 
side-by-side  comparison  of  the  top  three  architectures  identified  in  the  earlier  steps. 

Table  10  shows  the  top  three  ranked  options  that  the  team  chose  and  a  one-to-one 
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functional  comparison  of  these  options.  The  key  attributes  used  to  evaluate  the  options 
are  also  shown  in  Table  11;  key  attributes  included  engagement  mode,  engagement 
performance,  and  maneuverability.  The  architectures  were  also  evaluated  against  cost  and 
schedule  requirements  to  ensure  that  the  chosen  architecture  met  all  of  the  requirements 
created  during  the  ICD  and  CONOPS  portion  of  the  project. 


Table  10.  Concept  Architecture  Capabilities  and  Limitations 

Note:  The  comparison  analysis  performed  resulted  in  a  capabilities  and  limitations  definition  for 
each  candidate  architecture.  The  required  capability  to  combat  the  threat  was  identified  in  the 
problem  statement,  but  the  limitations  of  implementing  some  concept  architectures  could  result  in 
integration  challenges  that  may  render  the  entire  BMDS  system  less  agile  or  capable. 


Option  1 

Option  2 

Option  2a 

Operational 

Flexibility 

•  Allows  LoR  and  EoR 
due  to  compatibility 
with  C2BMC  and 
addition  of  CEC-D. 

•  Not  backwards 
compatible  with  SM-T. 

•  Allows  EoR  and  LoR 
due  to  compatibility 
with  C2BMC  via  Link 

16  capability. 

•  Allows  LoR  and  EoR 
due  to  compatibility 
with  C2BMC  and  the 
addition  of  CEC-D. 

•  Not  backwards 
compatible  with  SM-T. 

Implementation 

and 

Operational 

Deployment 

•  Zumwalt  system 
manages  onboard 
assets  and  sensors 
and  manages  missiles 
in  flight  via 

X-band  link. 

•  Midcourse  guidance 
updates  based  on 
remote  data  from 
external  BMDS 

sensors. 

•  Aegis  system 
manages  onboard 
sensors  and  missiles 
via  S-Band  link. 

•  Midcourse  guidance 
updates  based  on 
remote  data  from 
external  BMDS 
sensors. 

•  Aegis  system 
manages  onboard 
sensors  and  missiles 
via  S-Band  link. 

•  Midcourse  guidance 
updates  based  on 
remote  data  from 
external  BMDS 
sensors. 

Fire  Control 
Loop  Integrity 

•  Achieved  via 
local/organic  SPY-3 
radar  and/or 
external/remote 
sensors  via  the  BMDS 
network. 

•  Achieved  via 
local/organic 
(AN/SPY-1)  radar 
and/or  external/remote 
sensors  on  the  BMDS 
network. 

•  Achieved  via 

local/organic  SPY-3 
radar  and/or 
external/remote 
sensors  via  the  BMDS 
network.. 

Raid  Capability 

•  AN/SPY-1  can  provide 
additional  radar 
resources  for  search, 
tracking,  and 
discrimination. 
(Requires  new  C2BMC 
radar  control 
functionality.) 

•  SPY-3  can  provide 
additional  radar 
resources  for  search, 
tracking,  and 
discrimination. 
(Requires  new  C2BMC 
radar  control 
functionality.) 

•  AN/SPY-1  can  provide 
additional  radar 
resources  for  search, 
tracking,  and 
discrimination. 
(Requires  new  C2BMC 
radar  control 
functionality.) 
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Table  11.  Side-by-Side  Functional  Comparison 


Note:  The  side-by-side  functional  comparison  assists  in  identifying  the  most  capable  candidate 
architecture  when  compared  against  common  functional  performance  criteria. 


Option  1 

Option  2 

Option  2a 

Zumwalt/SPY-3 

Aegis  Baseline 

Aegis/SPY-3 

Primary  Engagement  Mode 

Engage-on-Remote 

(EoR) 

EoR 

EoR 

One-on-One  Engagement 
Performance 

Similar 

Battle  Space 
Performance 
One-on-One 

Launch 

Window 

Better:  Uses  SPY-3 
with  fully  populated 
array 

Better:  Uses  SPY-3 
with  fully  populated 
array 

Raid 

Small  Raid 

Similar 

Capacity 

Large  Raid 

Better:  Radar 
resources  greater  for 
in-flight  missiles 

Missile  Data  Link  Margin/ 
Information  Assurance  (IA) 

Better:  Uses  P3I  link 
with  X-band 

Better:  Uses  P3I  link 
with  X-band 

Cost 

Higher:  Requires 
additional  hardware 
and  advanced  program 
testing 

Best:  Leverages 
existing  resources 

Higher:  Requires 
additional  hardware 
and  advanced 
program  testing 

Schedule  and 

Programmatic  Risks 

Higher:  More 
challenging 
development, 
integration  and  testing 
effort 

Lower:  Shorter  build 
test  and  certify 
timeline  =  lower  cost 

Higher:  More 
challenging 
development, 
integration  and  testing 
effort 

Table  12  demonstrates  the  impact  of  modifications  that  each  system  introduces  to 
the  architecture.  Significant  changes  require  additional  time  and  funding  to  implement. 
Therefore,  options  requiring  extensive  changes  were  deemed  unable  to  meet  the  schedule 
constraints  of  the  project. 
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Table  12.  Comparison  of  Candidate  Architectures  by  Impact  of  Modification 

Note:  The  impact  of  changes  that  each  system  introduces  to  the  architecture  is  a  key  consideration 
in  making  the  final  decision.  Significant  changes  require  more  time  and  funding  to  implement. 
Therefore,  most  concept  architectures  requiring  extensive  changes  were  deemed  unable  to  meet 
the  schedule  constraints  of  the  project. 


Area  of  Modification 

Impact  of  Modification 

Option  1 

Zumwalt/SPY-3 

Option  2 
Aegis/SPY-1 

Option  2a 
Aegis/SPY-3 

External  Sensors 

None 

None 

None 

Missile 

Moderate 

None 

Moderate 

Core  Combat  Systems 

Negligible 

Negligible 

Negligible 

Launcher 

None 

None 

None 

Radar 

Significant 

None 

Significant 

D.  COST  ANALYSIS 

When  evaluating  cost,  comparing  candidate  alternatives  is  important  to  determine 
their  relative  costs  with  respect  to  a  baseline  set  of  requirements  or  capabilities.  The  three 
candidate  options  were  evaluated  to  determine  the  total  cost  of  implementation.  To 
ensure  that  a  fair  comparison  was  performed,  the  team  separated  the  costs  for  each  option 
into  two  separate  categories.  The  first  category  that  the  team  evaluated  was  the  cost  for 
software -related  changes,  including  requirements,  design,  code,  and  testing  needed  to 
upgrade  or  develop  the  required  capabilities.  The  estimated  software-related  costs  for 
each  of  the  candidate  architectures  are  shown  in  Figure  30. 
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Software  Cost 
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Note:  Software  cost  of  the  selected  architecture  helps  to  identify  the  resources  required  to  field  the 
system.  The  cost  analysis  was  a  significant  variable  in  the  concept  architecture  decision-making 
process. 

Figure  30.  Software  Cost 

The  second  category  of  cost  analysis  was  associated  with  hardware-related 
changes.  Some  options  required  few  hardware  changes,  as  most  of  their  required  updates 
were  only  changes  to  software  algorithms.  Figure  31  shows  the  comparison  of  the 
estimated  hardware-related  changes  for  the  candidate  architectures. 
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Hardware  Cost 
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Note:  The  hardware  cost  for  the  selected  architecture  is  key  to  ensuring  that  the  selected 
architecture  can  meet  the  schedule  requirements  of  the  system.  High  hardware  cost  is  always 
accompanied  by  testing  and  certification  costs,  which  are  significant  schedule  drivers. 

Figure  31.  Hardware  Cost 

Following  these  individual  software  and  hardware  cost  comparisons,  the  team 
conducted  a  total  cost  comparison  that  evaluated  software,  hardware,  and  system 
integration  costs  for  each  option.  The  comparison  of  the  total  cost  to  implement  each 
option  is  shown  in  Figure  32.  As  depicted  in  this  figure,  Option  2  was  determined  to  have 
the  lowest  total  development  cost. 
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Total  Development  Cost 
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Note:  Total  development  cost  is  the  total  cost  required  to  field  the  concept  architecture.  For  the 
purpose  of  this  study,  the  total  cost  is  the  sum  of  the  hardware  and  software  costs. 

Figure  32.  Total  Development  Cost 
E.  RISK  MANAGEMENT  SUMMARY 

Risk  management  is  a  concept  used  to  assess  and  handle  events  that  might 
adversely  impact  a  system  development  effort.  Mitigating  these  impacts  increases  the 
likelihood  of  a  successful  system  development  effort.  The  ASBMD  team  utilized  the  risk 
management  process  described  in  the  Risk  Management  Guide  for  DoD  Acquisition 
(DoD,  2006,  August).  Team  members  identified  the  risk  root  causes  in  the  areas  of 
project  management  and  systems  engineering,  and  each  root  cause  was  analyzed  for  the 
likelihood  of  the  event  occurrence  and  the  consequence  to  the  effort  upon  occurrence. 

The  team  developed  and  reviewed  risk  mitigation  plans  in  an  iterative  manner  throughout 
the  project  and  used  them  to  monitor  progress  toward  closure  of  each  risk.  Risk 
assessment  was  a  significant  aspect  of  the  AoA  process,  as  each  system  and  end-to-end 
architecture  option  was  considered  in  context  of  its  potential  to  introduce  risk  to  the 
system  or  mitigate  system  risk.  Several  architecture  options  were  eliminated  from  further 
evaluation  in  the  AoA  because  they  introduced  cost  and  schedule  risk  to  the  ASBMD 
system,  either  due  to  lack  of  maturity  or  to  an  assessed  inability  to  integrate  effectively 
with  the  BMDS.  The  team  used  this  information  to  aid  in  the  selection  of  the  option  that 
best  met  system  requirements  while  posing  the  least  perceived  risk  to  system  integration, 
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fielding,  and  performance.  More  information  about  the  risk  management  process  and  its 
use  by  the  ASBMD  team  is  available  in  Appendix  F. 

F.  FINAL  SELECTED  SOLUTION 
1.  Core  Solution  Architecture 

As  previously  described,  each  candidate  architecture  option  was  ranked  and 
evaluated  based  on  its  ability  to  meet  the  identified  functional  and  programmatic 
requirements  of  the  ASBMD  System.  The  selection  of  the  core  solution  architecture  from 
the  final  three  evaluated  options  was  based  on  the  primary  objective  of  eliminating  the 
ASBM  threat  during  the  midcourse  phase  of  ballistic  flight.  This  approach  requires  the 
system  solution  to  communicate  efficiently  and  effectively  within  the  BMDS  network 
and  on  the  capability  of  receiving  and  processing  data  from  all  network  sources. 
Stakeholder  concerns  related  to  interoperability  and  performance  were  balanced  by  the 
team  with  the  cost  and  schedule  constraints  associated  with  the  needs  statement.  These 
factors  were  applied  during  the  AoA  to  determine  the  best  system  of  systems  solution  for 
the  ASBMD  system.  The  side-by-side  functional  and  programmatic  comparisons,  cost 
analyses,  and  risk  assessment  of  the  final  three  options  clearly  show  that  Option  2  was  the 
best  fit  for  the  ASBMD  System  requirements.  Figure  33  shows  this  option’s 
configuration  in  detail  and  depicts  the  overall  architecture  of  the  core  solution. 
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Note:  The  selected  core  architecture  consists  of  the  Aegis  Combat  System  and  the  SM-3.  This 
architecture  relies  heavily  on  a  software  baseline  upgrade  to  introduce  the  ability  to  eliminate  the 
ASBM  threat. 


Figure  33.  Selected  Core  Architecture 


G.  AOA  SUMMARY 


As  described  in  this  chapter,  the  purpose  of  the  ASBMD  AoA  was  to  determine 
the  single  recommended  architecture  that  meets  the  functional  requirements,  schedule, 
and  cost  constraints  associated  with  a  solution  to  the  problem  statement.  The 
recommended  solution — Option  2 — includes  multiple  systems  that,  when  integrated,  will 
function  as  a  single  combat  system  to  defeat  the  ASBM  threat.  The  discussion  of  how  the 
system  is  integrated  follows  in  Chapter  IV. 
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IV.  INTEGRATED  SYSTEM  SOLUTION 


A.  PURPOSE 

As  described  in  Chapter  III,  the  team  implemented  the  modified  AoA  process  and 
conducted  a  detailed  analysis  to  identify  the  candidate  architecture  that  could  be  used  to 
fill  the  stated  capability  gap.  The  team  provided  detailed  pros  and  cons  for  each  system 
and  element  of  each  candidate  architecture  to  help  select  the  final  configuration  that  best 
met  the  functional  and  programmatic  requirements.  The  team  described  methods  used  to 
narrow  the  candidate  architectures  into  a  single  set  of  systems  or  elements  that  could 
fulfill  each  function  identified  as  part  of  the  functional  area  analysis  portion  of  the 
project.  Chapter  IV  will  detail  the  final  recommended  architecture  in  a  system-of- systems 
context  and  will  further  identify  a  total  fleet  solution  to  ensure  layered  capabilities.  The 
fleet  solution  creates  a  more  robust  system  that  is  considered  by  the  team  to  be  capable  of 
defeating  the  identified  threat,  even  under  off-nominal  conditions.  The  recommended 
architecture,  Option  2,  was  chosen  by  considering  all  technical  and  operational  aspects  of 
the  problem  and  identifying  risks  that  result  from  the  implementation  of  the  solution. 

B.  ADDITIONAL  ARCHITECTURE  CONSIDERATIONS 

(LAYERED  DEFENSE  CAPABILITIES) 

1.  Operational  Employment 

As  described  earlier  in  this  report,  the  team  defined  a  core  architecture  that  could 
defeat  the  threat  set  using  the  existing  BMDS  assets,  while  not  degrading  existing  BMDS 
capabilities.  As  the  project  progressed,  it  became  clear  that  a  layered  defense  approach, 
including  additional  architectures,  would  be  required  in  order  to  best  defend  against  the 
unique  capabilities  of  the  ASBM  threat.  The  team’s  primary  approach  was  to  engage  and 
destroy  the  target  exoatmospherically  to  ensure  that  the  target  was  not  able  to  begin  its 
reentry  maneuver.  The  team  recognized,  however,  that  additional  terminal  phase  defense 
capabilities  should  be  considered  in  concert  with  a  midcourse  capability,  in  the  event  that 
the  target  is  not  intercepted  in  the  midcourse  phase  and  reenters  the  atmosphere.  A  logical 
consideration  for  a  backup  terminal  phase  intercept  capability  was  the  SM-T  missile. 
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The  team  performed  a  PK  analysis  to  determine  the  ability  of  current  fleet  assets 
to  meet  the  PK  requirements  of  the  project.  The  team  analyzed  the  SM-3,  SM-T,  and 
mixed-salvo  options  to  determine  the  PK  for  each  scenario.  Due  to  the  classification  of 
the  data  required  to  compute  the  PK  for  both  the  SM-3  and  SM-T,  the  team  used  alternate 
analysis  techniques  to  obtain  representative  data.  The  techniques  included  using  notional 
timing  data  for  AAW  functions  of  similar  systems,  including  the  KA  timeline  for  both  the 
Aegis  and  Zumwalt  fire  control  systems.  The  team  also  used  engineering-level 
discussions  with  both  Government  and  contract  engineers  that  are  experienced  with  the 
representative  systems  to  obtain  the  data  needed  to  assist  in  the  comparative  analysis. 
Using  the  described  analysis  techniques,  the  team  performed  a  detailed  analysis  of  the 
effects  of  multiple  CONOPS  changes  to  increase  the  ability  of  the  concept  architecture  to 
combat  the  threat. 

The  first  CONOPS  modification  identified  was  the  need  to  alter  the  firing  policy 
to  raise  the  PK  of  the  exoatmosheperic  portion  of  the  engagement.  A  graphical 
representation  of  the  results  of  the  firing  policy  vs.  PK  analysis  for  both  the  SM-3  and 
SM-T  missiles  is  depicted  in  Table  13.  The  only  ordnance  currently  in  the  fleet  that  can 
intercept  this  threat  exoatmospherically  is  the  SM-3  missile;  the  team  initially 
investigated  the  effects  of  the  firing  policy  changes  using  the  SM-3  Missile.  The  SM-T 
portion  of  the  analysis  was  conducted  to  determine  the  feasibility  of  its  use  as  a 
complementary  system  to  the  selected  core  architecture  for  a  layered  defense  capability. 
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Table  13.  Firing  Policy  vs.  PK  Analysis  for  SM-3  and  SM-T  Missiles 

Note:  The  ability  to  increase  the  PK  by  modifying  the  firing  policy  or  by  salvo  size  is  key  to 
meeting  the  required  timelines  of  the  ASBMD  System. 


Missile 

Type 

PK  (Rating)  Exoatmospheric 

PK  (Rating)  Endoatmospheric 

PK  (Rating)  Mixed 

Shoot 

Shoot-Shoot 

Shoot-Shoot-Shoot 

Shoot 

Shoot-Shoot 

Shoot-Shoot-Shoot 

Shoot 

Shoot-Shoot 

Shoot-Shoot-Shoot 

SM-3 

Fair 

Fair/Good 

N/A 

N/A  (Not  Capable  of  Endo.  Intercept) 

N/A  (Not  Capable  of  Endo.  Intercept) 

SM-T 

Poor 

Poor 

Fair 

Good 

Good 

Excellent 

Depends  on  the  Mix/Not  Evaluated 

*Mixed 

Fair 

Fair/Good 

N/A 

N/A 

N/A 

Good 

Fair 

Fair/Good 

Excellent 

*  Mixed  assumes  that  the  first  two  salvos  will  be  SM-3s,  and  third  salvo  is  SM-T. 


As  Table  13  shows,  the  PK  of  the  concept  architecture  against  the  identified  threat 
was  increased  by  employing  a  shoot-shoot  firing  policy.  As  a  follow-on  to  this  analysis, 
the  team  also  investigated  a  layered  defense  CONOPS  change  using  a  mixed  load-out  of 
SM-3  and  SM-T  missiles.  The  scenario  evaluated  called  for  the  ship  to  perform  the  initial 
engagement,  using  a  dual-salvo  SM-3  policy  while  the  target  was  still  in  the 
exoatmosphere  and  to  perform  the  KA.  If  a  positive  no-kill  was  received,  the  ship  would 
then  fire  a  SM-T  as  a  backup  attempt  to  intercept  the  target  in  the  upper  endoatmosphere 
prior  to  its  terminal  phase  maneuver.  Unfortunately,  the  analysis  performed  by  the  team 
during  the  AoA  phase  of  this  project  showed  that  the  time  required  to  perform  the  KA 
was  greater  than  the  available  time  in  this  scenario. 

As  a  work-around  to  this  limitation,  the  team  evaluated  the  effects  of  using  a 
mixed  salvo  with  a  shoot-shoot-shoot-look  policy  on  the  PK  of  the  system.  The  CONOPS 
for  this  solution  would  be  for  the  ship  to  perform  an  initial  dual-salvo  SM-3  engagement 
when  the  threat  is  at  apogee.  The  system  would  continue  to  engage  the  threat  and  launch 
an  SM-T  missile  at  a  time  in  the  engagement  window  calculated  to  ensure  that  the 
intercept  would  be  achieved  before  the  target  has  begun  its  final  terminal  maneuver.  The 
team  looked  at  the  inclusion  of  the  SM-T  as  a  complementary  solution  that  applies  only 
to  the  Option  2  architecture,  since  it  is  not  functionally  compatible  with  all  candidate 
architectures  evaluated  during  the  AoA  process.  When  analyzed,  it  was  determined  that 
this  layered  solution  provided  a  greater  probability  of  mission  success  at  a  significantly 
lower  cost  (refer  to  Table  13).  Although  the  SM-T  is  no  longer  in  production,  the  team 
concluded  that  the  remaining  inventory  (~  80  missiles)  was  sufficient  to  support  the 
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near-term  fleet  requirements,  given  the  current  projected  threat  production  capability 
(Office  of  Naval  Intelligence,  2009,  July).  Thus,  the  use  of  this  tactic  was  the  most 
effective  and  practical  fit  for  the  system  solution.  Note  that  SM-T  performance  against 
maneuvering  threats  has  not  been  assessed  and  requires  additional  study.  For  the 
purposes  of  this  assessment,  the  assumption  was  made  that  the  SM-T  would  intercept  the 
threat  early  in  the  terminal  phase,  prior  to  its  maneuver. 

With  respect  to  combat  system  integration  and  fire  control,  the  SM-T  uses  the 
common  S-Band  missile  uplinks  for  acquisition  and  midcourse  guidance  and  employs  an 
on-board  active  seeker  during  terminal  phase.  This  eliminates  the  need  for  detailed 
analysis  of  the  capabilities  (e.g.,  range  and  power)  of  the  MK-99  fire  control  illuminators. 

2.  Additional  System  Considerations 

The  team  investigated  additional  complementary  solutions  that  could  be 
integrated  with  any  of  the  candidate  architectures  and  employed  to  assist  in  the 
elimination  of  the  threat.  A  key  operational  criterion  of  the  threat  group  is  that  it  uses  a 
global  positioning  system  (GPS)  as  a  guidance  source  during  the  midcourse  and  terminal 
phases  of  flight.  The  team  investigated  use  of  a  GPS  transponder,  deployed  on  a  vehicle 
in  the  upper  endoatmosphere,  to  disrupt  communication  with  the  combatant's  GPS 
satellite  and  effectively  “walk”  the  threat  away  from  the  CSG  by  feeding  the  threat  bad 
GPS  data.  Because  all  GPS  variants  essentially  use  the  same  phase  shift  keying 
modulation  scheme  (most  are  biphase  shift  keying  (bpsk))  and  have  a  similar  power 
output,  consistent  interference  techniques  could  be  developed  that  exploit  the  reliance  of 
a  broad  range  of  threats  on  a  variety  of  GPS  systems.  Use  of  omnidirectional  GPS 
antennas  on  the  interference  source  vehicle  would  help  ensure  timely  acquisition  of  the 
spoofed  GPS  signal  by  the  threat. 
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Employment  of  this  concept  assumes  that  several  conditions  would  be  met: 

•  The  CSG  receives  intelligence  data  indicating  a  probable  or  imminent  launch, 
and  the  appropriate  mission  plan  is  developed  with  enough  notice  to  launch 
and  position  the  vehicle. 

•  The  vehicle  is  capable  of  operating  in  the  upper  endoatmosphere,  has 
sufficient  range  to  reach  the  required  altitude,  and  can  operate  in  thin 
atmosphere. 

•  The  vehicle  has  sufficient  endurance  to  perform  loiter  maneuvers  for  a  period 
of  multiple  hours  once  on  station  and  at  the  desired  altitude. 

•  The  vehicle  is  capable  of  powering  the  GPS  transponder,  and  the  GPS  signal 
strength  will  be  greater  than  that  of  the  combatant's  GPS  satellite  (-130  dBm). 
A  moderately  higher  signal  (approximately  20  dB  higher)  would  be  sufficient 
to  overwhelm  the  threat  GPS  signal. 

Once  the  threat  encounters  and  acquires  the  false  GPS  signal,  it  is  anticipated  that 
the  threat  would  attempt  a  course  correction.  Any  course  adjustments  this  late  in  flight 
would  be  occurring  while  the  threat  is  moving  very  fast.  Even  if  the  dummy  GPS  signal 
were  lost  and  the  satellite  were  reacquired,  it  is  unlikely  that  the  threat  would  have 
sufficient  time  to  reposition  itself  to  close  on  the  intended  target  (i.e.,  a  carrier).  Further, 
the  GPS  vehicle  could  be  maneuvered  away  from  the  flight  path  once  the  threat  acquires 
the  signal,  drawing  the  threat  away  from  the  CSG  and  ideally  to  a  location  where  it  could 
impact  the  ocean  or  be  put  within  lethal  range  of  conventional  shipboard  weapons. 

Other  potential  options  for  this  concept  could  include  a  launch  of  multiple 
vehicles  carrying  GPS  transponders  to  create  an  interference  source  over  a  wide 
operational  area.  Use  of  multiple  Tomahawk  Land  Attack  Missile  (TLAM)  vehicles  in 
this  manner,  spread  over  an  operational  area  with  different  loiter  patterns,  would  be 
sufficient  to  disrupt  multiple  threats.  This  could  potentially  increase  the  coverage  area, 
especially  if  intelligence  indicates  the  likelihood  of  multiple  launches  from  a  single  site, 
multiple  active  sites,  or  that  the  active  launch  units  are  mobile.  This  technique  may  also 
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be  effective  in  dealing  with  multiple  threats  launched  in  a  raid  configuration  and  could 
solve  the  potential  discrimination  issue  of  threat  evaluation  and  weapons  assignment 
(TEW A)  by  exploiting  the  GPS  dependency  of  all  threats  in  the  raid. 

Because  the  vehicle-borne  GPS  transponder  solution  was  approached  as  a 
complementary  architecture  that  could  supplement  any  of  the  possible  selected  core 
system  architectures,  it  was  also  desired  that  the  vehicle  be  a  low-cost  and  easily 
integrated  option.  Ideally,  an  existing  vehicle  that  is  common  to  CSGs  and  could  be 
retrofitted  with  a  GPS  transponder  would  be  selected  for  this  task.  This  would  add 
additional  capability  to  the  system  at  a  fraction  of  the  cost  and  time  required  to  develop  a 
new  vehicle  expressly  for  this  purpose. 

The  team  first  analyzed  the  feasibility  of  using  an  Unmanned  Aerial  Vehicle 
(UAV)  to  fill  this  role.  The  MQ-8B  Fire  Scout  UAV  was  the  specific  unit  considered  due 
to  the  inventory  approved  for  the  recent  initial  deployment  on  Guided  Missile  Frigates 
(FFG)  and  planned  deployment  on  the  Littoral  Combat  Ship  (LCS)  and  DDG  1000 
platforms.  The  concept  was  to  launch  the  UAV  well  in  advance  of  the  arrival  of  the 
threat;  the  UAV  would  loiter  in  the  flight  path  between  the  expected  launch  point  and  the 
battlegroup  while  operating  the  GPS  transponder.  A  graphical  representation  of  this 
concept  is  shown  in  Figure  34. 
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Note:  The  use  of  a  UAV  to  carry  a  GPS-interference  source  across  the  flight  path  of  the  incoming 
threat  was  analyzed  as  a  potential  complementary  architecture  to  augment  any  of  the  candidate 
ASBMD  architectures.  It  is  shown  here  in  complement  to  the  selected  Aegis  Combat  System 
architecture. 

Figure  34.  UAV  GPS  Interference  Option 

This  capability  appeared  feasible,  because  when  the  CSG  is  operating  within  the 
threat's  capability  range,  the  group  should  have  consistent  and  quality  intelligence 
reporting  on  the  anticipated  launch  sites.  The  intelligence  would  allow  for  advance 
planning  and  UAV  launch  staging  for  faster  response  and  on-station  times  prior  to  a 
threat  launch.  An  analysis  of  this  option  concluded  that  the  MQ-8B  Fire  Scout  was 
unsuitable  for  this  type  of  mission  since  it  does  not  have  the  capability  to  achieve  and 
maintain  the  required  altitude,  due  to  the  environment  that  the  UAV  would  encounter  in 
the  upper  endoatmosphere.  Additionally,  the  MQ-8B  top  speed  only  supports  a  maximum 
notice  scenario.  It  is  unlikely  that  the  MQ-8B  could  be  readied,  launched,  and  positioned 
in  time-critical  scenarios  to  support  this  mission.  The  lack  of  widespread  fielding  or 
available  launch  platforms  for  the  MQ-8B  further  limited  consideration  of  it  as  a  viable 
option  for  this  capability. 
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The  second  option  that  the  team  investigated  was  the  use  of  a  TLAM  as  the  GPS- 
transponder  vehicle.  This  option  is  depicted  in  Figure  35. 


Note:  The  use  of  a  TLAM  to  carry  a  GPS-interference  source  across  the  flight  path  of  the 
incoming  threat  was  analyzed  as  a  potential  complementary  architecture  to  augment  any  of  the 
candidate  ASBMD  architectures.  It  is  shown  here  in  complement  to  the  selected  Aegis  Combat 
System  architecture. 

Figure  35.  TLAM  GPS  Interference  Option 

The  team  concluded  that  the  TLAM  option  was  more  technically  feasible  than  the 
UAV  option,  since  the  newer  TLAM  (Block  IV) — while  not  designed  for  use  in  the  upper 
endoatmosphere — is  capable  of  achieving  the  desired  altitude.  The  TLAM  has  a  built-in 
loiter  mission  that  can  be  sustained  for  as  long  as  its  remaining  fuel  permits.  Because  the 
TLAM  is  not  designed  to  operate  in  the  upper  endoatmosphere,  it  would  be  necessary  to 
bring  the  missile  up  to  the  required  altitude  at  a  lower  speed  than  typically  employed  for 
its  flyout  to  minimize  the  risk  of  compromising  the  structural  integrity  of  the  missile.  The 
ability  to  have  advanced  knowledge  of  the  threat  launch  is  again  very  critical  to  this 
option.  The  nominal  mission  planning  and  launch  time  for  a  new,  no-notice  mission  is 
approximately  10  minutes  for  a  Block  IV  TLAM.  For  a  predefined  Block  IV  mission 
scenario,  the  required  time  is  reduced  to  5  minutes.  Operating  at  a  lower  speed,  the 
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TLAM  could  have  a  nominal  flight  time  of  approximately  15  minutes  (i.e.,  a  20-nautical 
mile  (nm)  range  at  a  165,000-foot  altitude)  to  allow  the  TLAM  to  be  positioned  on  station 
in  time  to  begin  its  loiter  and  disrupt  the  threat.  Although  a  total,  on-station  readiness 
window  of  20  to  25  minutes  is  good,  this  demonstrates  the  need  for  intelligence 
indicators  of  a  pending  threat  launch.  It  is  not  a  viable  option  for  backing  up  the  core 
architecture  in  scenarios  where  no  advance  notice  is  received. 

3.  Fully  Integrated  Operational  Solution  (Based  on  Option  2) 

A  graphical  representation  of  the  fully  integrated  recommended  solution,  based  on 
Option  2  and  including  the  SM-T  and  TLAM  complementary  solutions,  is  depicted  below 
in  Figure  36.  As  discussed  in  Chapter  III,  the  fully  integrated  solution  meets  the  key 
functional  requirements,  as  well  as  cost  and  schedule  constraints  of  the  project. 


Note:  The  fully  integrated  architecture  for  the  ASBMD  system,  based  on  Option  2,  includes  the 
core  Aegis  Combat  System  and  the  SM-T  and  TLAM  complementary  systems.  The  ability  to  fully 
integrate  these  elements  into  a  system  of  systems  is  key  to  mission  success  in  the  ASBMD 
scenario. 


Figure  36.  Fully  Integrated  ASBMD  System  Architecture 
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As  depicted  in  Figure  36,  if  the  equipped  ship  receives  advanced  intelligence 
cueing,  the  crew  would  create  and  execute  a  TLAM  mission  plan  to  launch  the  TLAM  for 
the  interference  mission.  If  no  advance  intelligence  data  were  available,  the  launch  of  the 
TLAM  would  not  be  used  as  part  of  the  engagement.  After  launch  of  the  threat,  the 
equipped  ship  would  begin  receiving  BMD  data  across  the  BMDS  network.  The  data 
would  include  a  composite  system  track  that  is  made  up  of  fused  Link- 16  and  CEC  data 
from  remote,  forward-based  sensors.  Since  the  fire  control  algorithms  have  been 
optimized,  the  Aegis  Weapons  Control  System  (WCS)  would  recommend  a  launch  time 
that  would  ensure  that  the  time  to  intercept  of  the  first  dual-salvo  SM-3s  would  be  at  the 
point  that  the  threat  has  just  reached  apogee.  This  optimization  is  key  to  mission  success 
since  it  ensures  that  the  threat  is  intercepted  at  the  point  in  flight  where  the  target  presents 
the  largest  cross  section  before  the  SM-3  intercepts. 

Upon  launch  of  the  first  salvo  of  SM-3  missiles,  the  ship  would  begin  planning 
the  launch  of  the  second  salvo,  consisting  of  the  SM-T  interceptor  to  ensure  the  layered 
defense  capability  that  was  described  in  section  2  of  this  chapter.  As  the  first  salvo  of 
SM-3  missiles  breaches  the  atmosphere,  the  TLAM  would  begin  transmitting  GPS 
interference  along  the  flight  path  of  the  threat.  Ensuring  that  the  SM-3s  have  exited  the 
atmosphere  before  initiating  the  GPS  interference  is  critical  to  mission  success,  since  the 
interference  could  also  impact  the  guidance  of  the  SM-3.  Prior  to  the  actual  engagement 
of  the  first  salvo  of  SM-3,  the  updated  Aegis  fire  control  system  would  determine  a  need 
to  launch  the  SM-T  missile  and  ensure  intercept  in  the  upper  endoatmosphere  before  the 
threat  has  begun  its  terminal  maneuver.  Upon  engagement  of  the  threat  by  the  first  salvo 
(i.e.,  dual-salvo  SM-3s),  the  system  would  use  both  organic  and  BMDS  nonorganic  data 
to  perform  a  KA.  If  the  KA  returns  a  positive  kill,  the  threat  has  been  eliminated,  and  the 
fire  control  system  would  terminate  the  SM-T  portion  of  the  mission  and  self-destruct  the 
SM-T  missile.  The  mission  would  be  considered  complete.  If  the  system  determines  that 
the  threat  remains  active,  a  status  of  no-kill  would  be  reported,  and  the  system  would 
continue  to  consummate  the  SM-T  portion  of  the  engagement  sequence.  This  weapon 
requires  organic  radar  control  commands  until  the  threat’s  terminal  phase  of  flight. 
Therefore,  resources  would  be  prioritized  to  ensure  sufficient  guidance  could  be  provided 
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until  the  SM-T  is  within  range  of  the  threat.  Following  the  SM-T  engagement,  the  same 
KA  described  above  would  occur. 

Although  the  specific  firing  policy  updates  to  the  CONOPS  are  not  employed 
today,  the  selected  system  solution  would  be  compatible  overall  with  current  fleet 
CONOPS  and  could  be  implemented  with  minimal  impact  and  additional  resources.  The 
current  fleet  CONOPS  provides  for  at  least  one  BMD-equipped  Aegis  cruiser  or 
destroyer  within  each  CSG.  Implementation  of  the  ASBMD  architecture  would  not 
change  the  current  CONOPS  but  would  require  that  the  Aegis  ship  be  equipped  with  the 
recommended  system  solution.  The  operational  implementation  of  this  system  would 
include  the  plan  to  backfit  the  current  BMD-equipped  Aegis  cruisers  and  destroyers  to 
ensure  a  sufficient  number  would  be  available  to  support  the  CSG  CONOPS.  The 
ASBMD  capability  should  be  fielded  in  accordance  with  the  BMD  baseline  installation, 
fielding,  and  maintenance  plan  so  that  the  system  could  be  deployed  at  minimal  cost.  If 
desired,  the  ASBMD  architecture  could  be  backfit  in  additional  ships  as  new  BMD  ships 
are  brought  online,  in  accordance  with  the  baseline  installation  schedule. 
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V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  OVERVIEW 

The  ASBMD  team  applied  and  maintained  compliance  successfully  with  a 
rigorous,  tailored  systems  engineering  process.  The  team  created  and  followed  a 
comprehensive  and  challenging  schedule  to  ensure  that  research  and  development  of  the 
ASBMD  System  solution  met  the  timelines  identified  at  the  beginning  of  the  project.  As 
defined  in  Chapters  II  and  III,  the  team  followed  a  tailored  version  of  the  systems 
engineering  “V”  model  and  focused  on  creation  of  a  key  set  of  analysis  artifacts  and 
program  documentation.  The  objective  was  to  design  and  communicate  a  robust  system 
architecture  that  could  fill  the  capability  gap  created  by  the  introduction  of  the  ASBM 
threat  set. 

Following  requirements  analysis  and  functional  decomposition,  the  team 
developed  and  analyzed  eight  core  system  solution  candidates  and  two  possible 
complementary  solutions.  Using  the  key  system  requirements  and  schedule  constraints  as 
the  bounding  factors  for  the  solution  space,  the  team  was  able  to  quickly  narrow  the 
concept  architectures  down  to  three.  Through  the  process  of  technical  feasibility 
screening,  the  team  was  able  to  determine  the  single,  best  fit  architecture  concept,  as 
described  in  Chapter  IV.  The  recommended  solution  is  based  on  Option  2  and  includes 
the  layered  defense  capabilities  provided  by  the  complementary  SM-T  and  TLAM 
systems,  as  shown  below  in  Figure  37. 
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Note:  The  fully  integrated  architecture  for  the  BMDS  system,  based  on  Option  2,  includes  the  core 
Aegis  Combat  System,  as  well  as  the  SM-T  and  TLAM  complementary  systems.  The  ability  to 
fully  integrate  these  elements  into  a  system  of  systems  is  key  to  mission  success  in  the  ASBMD 
scenario.  (This  figure  was  previously  presented  as  Figure  36.) 

Figure  37.  Fully  Integrated  ASBMD  System  Architecture 

These  analyses  focused  on  maximizing  the  detection  and  tracking  capabilities  of 
the  selected  architecture.  The  maximization  of  the  detection  and  tracking  ranges 
lengthens  the  engagement  window  and  ultimately  increases  the  ability  to  protect  the 
CSG.  Using  the  core  architecture,  as  described  in  Chapter  IV,  provides  the  ability  to 
deploy  quickly,  enhance  the  capability  of  the  BMDS,  and  use  existing  assets  without 
major  modification  to  the  current  fleet  CONOPS.  The  core  option  also  has  negligible 
impact  to  the  total  lifecycle  cost  of  the  existing  systems,  since  it  can  be  provided  as  an 
upgrade  to  the  current  fielded  assets  and  then  installed  during  the  next  scheduled 
installation  and  checkout  (INCO)  or  maintenance  availability. 

The  complementary  systems  defined  in  Chapter  IV,  if  implemented  as  designed, 
would  have  negligible  impact  to  the  current  BMDS  network,  but  would  require  a  fleet 
CONOPS  update  to  facilitate  the  early  warning  and  launch  requirements  to  support  the 
use  of  the  system  as  described.  The  total  lifecycle  cost  of  the  existing  weapon  system 
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would  still  be  unaffected  with  this  solution,  since  the  capabilities  already  exist  within  the 
current  fielded  assets. 

B.  FOLLOW-ON  RECOMMENDATIONS 

The  recommended  core  architecture  was  paired  with  two  complementary 
architectures,  SM-T  and  GPS,  to  further  layer  the  defensive  capability  of  the  ASBMD 
system.  While  both  of  these  complementary  concepts  were  deemed  feasible  by  the 
ASBMD  team  for  application  in  this  manner,  this  determination  was  made  via 
engineering  assessment  and  has  not  been  demonstrated  through  detailed  analysis  or  test. 
No  performance  characterization  has  been  conducted  for  either  technology  in  this 
scenario;  however,  further  study  of  both  applications  for  consideration  in  a  BMD 
architecture  is  recommended. 

In  addition  to  the  ASBMD  team’s  recommended  solution,  the  team  also 
recognized  that  it  would  be  beneficial  to  continue  to  pursue  the  long-term  development 
and  testing  of  Option  1,  as  defined  in  Chapter  III.  Pursuit  of  Option  1  would  ensure  that 
the  latest  technology  is  developed  with  the  ASBMD  mission  in  consideration  and  would 
extend  the  fleet’s  ability  to  combat  the  ASBM  threat  with  future  platforms.  As  discussed 
in  Chapter  III,  the  SPY-3  radar  would  advance  search  and  track  capabilities  beyond  that 
of  the  SPY-1  radar  currently  employed  in  the  Aegis  Combat  System.  The  Zumwalt 
Combat  System  would  also  bring  advanced  tracking  and  discrimination  algorithms  into 
service  and  will  provide  additional  capability  that  would  assist  in  lengthening  the 
battlespace  and  engagement  timeline  for  the  ASBM  threat. 

The  cost  analysis  for  Option  1  was  included  in  Chapter  IV.  Since  the  Zumwalt 
program  is  already  under  development  and  is  currently  funded  through  its  IOC,  an 
ASBMD  capability  for  Zumwalt  would  need  to  be  added  to  the  Zumwalt  Combat  System 
and  SPY-3  Radar.  This  would  require  additional  funding,  but  could  be  integrated  prior  to 
IOC  at  a  lower  cost  than  if  the  decision  to  implement  this  capability  in  Zumwalt  is  made 
following  delivery  of  the  platform. 


85 


This  page  is  intentionally  left  blank. 


86 


VI.  REFERENCES 


Chairman  of  the  Joint  Chiefs  of  Staff.  (2009,  March  1).  Joint  Capabilities  Integration  and 
Development  System  (CJCSI  3170.01G).  Washington,  DC:  Author. 

Defense  Acquisition  University.  (2009,  June  15).  Integrated  Defense  Acquisition, 
Technology  and  Logistics  Life  Cycle  Management  System  Chart  (Version  5.3.4). 
Washington,  DC:  Author. 

Department  of  Defense.  (2006,  August).  Risk  Management  Guide  for  DOD  Acquisition 
(Sixth  Edition,  Version  1.0).  Washington,  DC:  Author. 

Erickson,  A.  &  Yang,  D.  (2009).  On  the  Verge  of  a  Game-Changer.  U.S.  Naval  Institute 
Proceedings  Magazine,  153(5),  1,275. 

Missile  Defense  101:  ICBM  Fundamentals.  (2007,  May  9).  Retrieved  October  1,  2009 
from  Steeljaw  Scribe  website:  http://steeljawscribe.blogspot.com/2007/05/missile- 
defense- 101  -icbm-fundamentals.html. 

Missile  Defense  Agency.  (2009,  April).  Foreign  Ballistic  Missile  Capabilities. 
Huntsville,  AL:  Author. 

Office  of  Naval  Intelligence.  (2009,  July).  Office  of  Naval  Intelligence  Threat  Report. 
Washington,  DC:  Author. 

Pace,  D.  (2000).  Guest  Editor’s  Introduction.  Johns  Hopkins  Applied  Physics  Laboratory 
Technical  Digest,  21(2),  187-191. 

Sanders,  P.  (2007,  June  28).  Missile  Defense  Program  Overview  for  the  European  Union, 
Committee  on  Foreign  Affairs,  Subcommittee  on  Security  and  Defence. 
Unpublished  PowerPoint  presentation.  Public  release  document,  Missile  Defense 
Agency. 


87 


Ullman,  R.  (2006).  Making  Robust  Decisions:  Decision  Management  for  Technical, 
Business  &  Service  Teams.  Victoria,  BC,  Canada:  Trafford  Publishing. 

Under  Secretary  of  Defense  (AT&L).  (2008,  December  8).  Operation  of  the  Defense 
Acquisition  System  (DoDI  5000.02).  Washington,  DC:  Author. 


88 


iNPsij 

,  tmJ, mpfTLA  H i  % 


Naval  Postgraduate  School  (NPS) 
Capstone  Project 

Masters  of  Science  in  Systems  Engineering  (MSSE) 
ANTI-SHIP  BALLISTIC  MISSILE  DEFENSE  (ASBMD) 


APPENDIX  A 

PROJECT  MANAGEMENT  PLAN 


89 


This  page  is  intentionally  left  blank. 


90 


Appendix  A 


CONTENTS 

Section  Page 


1  INTRODUCTION . 95 

1 . 1  Project  Description . 95 

1.1.1  Problem  Statement . 95 

1 .2  Organization  Structure . 96 

1.2.1  Team  Membership . 97 

2  SYSTEMS  ENGINEERING  APPROACH . 98 

2.1  Overview . 99 

2.2  Team  Approach . 99 

2.2.1  Initial  Research . 100 

2.2.2  Stakeholder  Analysis . 100 

2.2.3  Problem  Formulation . 101 

2.2.3. 1  Perform  Functional  Area  Analysis . 101 

2.2.4  Analysis  of  Alternatives . 102 

2.2.4. 1  Developing  Alternatives . 102 

2.2.4.2  Generate  Metrics  to  Measure  Effectiveness/Performance . 103 

2.2.4. 3  Develop  Models  and  Simulations . 103 

2.2.5  System  Concept  Refinement/Finalization . 1 03 

2.2.5. 1  Cost  Analysis . 103 

2.2. 5.2  Risk  Analysis . 104 

2. 2. 5. 3  Sensitivity  Analysis . 105 

2.2. 5.4  Trade-off  Study . 105 

3  MILESTONES  AND  DELIVERABLES . 106 

3.1  Overview . 107 

3 .2  Deliverables . 107 

3.3  Schedule . 109 

4  REFERENCES . 110 


91 


Appendix  A 


ILLUSTRATIONS 

Figure  Page 


A-l  Modem  Carrier  Strike  Group  Underway 

[From  Strategypage.com,  2008] . 96 

A-2  ASMBD  OIPT  Structure . 97 

A-3  ASBMD  SEP  Approach . 99 

A-4  ASBMD  Functional  Hierarchy  (Notional) . 102 

A-5  Current  ASBMD  Risk  Management  Matrix . 104 

A-6  ASBMD  Focus  within  the  Defense  Acquisition  Process 

[Lifecycle  Framework  View] . 107 

A-7  ASBMD  Current  Project  Schedule . 109 


TABLES 

Table  Page 


A- 1  ASBMD  Team  Member  Contact  Information . 97 

A-2  Current  Risk  Description  for  ASBMD . 105 


92 


Appendix  A 
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1  INTRODUCTION 

1.1  PROJECT  DESCRIPTION 

The  members  of  this  team  have  been  tasked  with  investigating  a  system  solution 
to  counter  the  evolving  Land-Based  Anti-Ship  Ballistic  Missile  threat.  Current  reports 
indicate  that  multiple  countries  and  organizations  have  funded  research  and  development 
of  missile  systems  specifically  designed  to  target  sea-going  vessels,  including  U.S. 
warships  and  aircraft  carriers.  This  plan  identifies  the  key  tasks  that  the  team  will 
accomplish  to  research  and  identify  a  recommended  architecture  for  a  robust  system  of 
systems  solution  that  may  be  developed  to  counter  such  threats. 

1.1.1  Problem  Statement 

A  recent  article  in  the  U.S.  Naval  Institute ’s  Proceedings  Magazine  has  suggested 
that  China  is  developing  ballistic  missiles  that  can  be  used  against  moving  targets,  such 
as  ships.  One  such  technology  is  said  to  be  able  to  cover  a  range  of  2,000  kilometers  (km) 
and  operate  at  a  speed  of  Mach  10.  This  type  of  threat  from  China,  or  any  other  nation, 
could  greatly  impact  the  current  concept  of  operations  of  U.S.  Navy  ships.  While  there 
are  currently  some  individual  solutions  capable  of  providing  partial  defense  in  specific 
mission  scenarios,  no  comprehensive  system  has  been  developed  to  counter  this  threat 
post-launch.  To  fulfill  this  need,  the  Anti-Ship  Ballistic  Missile  Defense  (ASBMD)  team 
will  propose  a  notional  architecture  for  a  system  of  systems  that  could  be  used  to 
effectively  counter  this  threat. 
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Figure  A-l.  Modern  Carrier  Strike  Group  Underway 
[From  Strategypage.com,  2008] 

1.2  ORGANIZATION  STRUCTURE 

The  ASBMD  team  has  decided  to  structure  ourselves  into  Integrated  Product 
Teams  (IPTs),  headed  by  a  Team  Lead.  Each  IPT  Lead  is  a  member  of  the  Overarching- 
Level  Integrated  Product  Team  (OIPT)  headed  by  the  Project  Manager  (PM).  This 
philosophy  is  expressed  pictorially  below  in  Figure  A-2.  The  IPT  structure  directly  maps 
to  the  Systems  Engineering  approach  that  we  have  chosen.  The  Systems  Engineering 
philosophy  will  be  discussed  later  in  this  document.  IPTs  will  be  established  as  necessary 
to  perform  the  analysis  and  meet  project  objectives  within  each  project  phase.  As  an  IPT 
completes  its  assigned  tasking,  the  IPT  Lead  will  report  out  to  the  OIPT/PM  and 
members  will  populate  or  update  their  portion  of  the  Capstone  report.  Upon  completion 
and  review  of  the  relevant  sections  of  the  Capstone  report,  the  IPT  team  members  will  be 
reassigned  as  necessary  to  support  other  tasking.  The  OIPT  is  responsible  for  identifying 
the  Working  IPT  (WIPT)  requirements  throughout  each  project  phase. 
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1.2.1  Team  Membership 

Table  A-l  provides  the  names  and  contact  information  for  each  of  the  ASBMD 
team  members. 


Table  A-l.  ASBMD  Team  Member  Contact  Information 


Name 

Organization 

E-mail 

Phone 

Role 

Hobgood,  Jean 

NSWCDD/K54 

j  ean.hobgood@navy.mil 
(540)  653-2968 

Technical  Editor, 

Risk  Manager 

Madison,  Kim 

NSWCDD/W63 

madisonkg@gmail.com 
(540)  653-6745 

Data  Librarian 

Nedd,  Steven 

TACOM 

steven.nedd@us.army.mil 
(584)  574-7928 

Modeling  Specialist 

Pawlowski,  Geoff 

NSWCCD  2110 

geoffrey.pawlowski@navy.mil 
(301)  227-3661 

Cost  Analyst 

Roberts,  Michael 

NSWCDD/W51 

michael.w.roberts@navy.mil 
(202)  406-4250 

Lead  System  Analyst 

Rumberg,  Paige 

NSWCDD/Q51 

paige.rumberg@navy.mil 
(540)  653-3478 

Team  Lead,  Scheduler 
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2  SYSTEMS  ENGINEERING  APPROACH 


2.1  OVERVIEW 

A  tailored  Systems  Engineering  Process  (SEP)  will  be  utilized  in  the  performance 
of  this  Naval  Postgraduate  School  (NPS)  Capstone  Project.  The  SEP  process  chosen  by 
the  ASBMD  team  will  be  based  on  the  V  model,  one  of  the  SEP  frameworks  outlined  in 
the  NPS  System  Engineering  Curriculum.  A  representation  of  the  V  model  being  used  by 
the  ASBMD  team  is  shown  in  Figure  A-3. 


Concept  Refinement  Phase 


OUTPUTS 


Figure  A-3.  ASBMD  SEP  Approach 
2.2  TEAM  APPROACH 

The  tailored  version  of  the  V  model,  shown  in  Figure  A-3,  will  be  used  by  our 
team  to  develop  a  notional  system  architecture  that  can  be  used  to  effectively  defend 
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against  anti-ship  ballistic  missiles.  At  a  fundamental  level,  the  rationale  for  using  a 
Systems  Engineering  V  process  is  founded  on  the  idea  that  it  can  provide  an  organized 
approach  to  problem  resolution,  according  to  the  Sage  and  Armstrong  text,  Introduction 
to  Systems  Engineering. 

The  focus  of  this  project,  as  our  team  has  defined  it,  will  be  to  address  the 
Concept  Refinement  phase  of  the  Defense  Acquisition  Process.  Specifically  in  this  phase, 
we  will  be  focusing  on  developing  high-level  Concept  of  Operations  (CONOPS), 
requirements,  and  system-level  architecture  artifacts.  We  feel  that  the  SEP  V  process  is 
appropriate  for  our  use,  because  the  project  focuses  on  performing  early  acquisition  phase 
conceptual  definition  and  the  supporting  functional  analysis. 

2.2.1  Initial  Research 

With  the  problem  statement  identified  during  the  initial  phase  of  the  project,  and 
the  overall  goal  of  the  project  outlined,  the  initial  research  will  be  conducted  covering  all 
aspects  of  the  problem.  The  team  will  be  leveraging  both  public  domain  documentation 
and  personal  experiences  to  understand  the  detailed  functional  aspects  of  the  problem. 

The  team  will  research  the  capabilities  and  functional  makeup  of  the  basic  threats  that 
were  identified  in  the  initial  problem  statement.  Understanding  the  threats  and  existing 
system  capabilities  will  assist  us  in  defining  the  system  that  can  effectively  combat  the 
threats.  Each  of  the  topics  chosen  will  be  related  to  the  SEP  to  ensure  that  the  boundaries 
of  the  problem  statement  are  maintained. 

2.2.2  Stakeholder  Analysis 

During  the  stakeholder  analysis  phase,  the  individuals  with  a  vested  interest  in  a 
system  that  can  achieve  the  objectives  described  in  the  problem  statement  will  be 
identified  and  categorized  according  to  their  influences  on  the  system.  The  output  of  this 
phase  will  be  a  weighted  scale  that  will  ensure  that  stakeholder  needs  have  precedence  in 
the  decision-making  process.  Stakeholder  inputs  will  be  collected  by  surveys,  interviews, 
or  focus  groups;  these  inputs  will  be  used  to  derive  system  requirements  and  needs.  The 
team  will  use  the  Quality  Function  Deployment  (QFD)  model  and/or  Pareto  Analysis  to 
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both  ensure  that  the  customer  inputs  are  understood,  and  to  prioritize  inputs  so  that  the 
most  significant  issues  are  examined.  Weighting  of  system  requirements  will  allow  the 
team  to  tailor  the  analysis  phase  so  that  only  the  most  viable  alternatives  are  evaluated. 

2.2.3  Problem  Formulation 

In  this  phase,  the  project  team  will  refine  the  problem  definition  to  confirm  that  it 
remains  scoped  within  the  timeline  and  boundary  of  the  project  as  we  have  defined  it. 
This  process  will  involve  the  performance  of  functional  analysis  to  understand  what  the 
system  must  accomplish,  and  the  development  of  a  functional  architecture  that  outlines 
the  sequence  and  structure  of  the  tasks  identified  during  functional  analysis. 

2.2.3. 1  Perform  Functional  Area  Analysis 

As  stated  in  Blanchard  and  Fabrycky’s  Systems  Engineering  and  Analysis,  the 
functional  area  analysis  portion  of  any  system  engineering  process  is  a  critical  step.  In 
this  task  we  will  use  the  functional  need  statement,  derived  from  the  stakeholder  analysis 
performed  in  earlier  steps,  to  define  the  system  needs  and  basic  requirements  from  the 
system  level  down  to  the  applicable  level  of  detail.  Per  the  direction  provided  during  the 
NPS  Systems  Engineering  curriculum,  the  objective  of  functional  analysis  is  to  specify 
the  “what’s”  that  need  to  be  accomplished.  We  plan  to  use  Figure  A-4  as  a  starting  point 
for  our  functional  hierarchy.  This  notional  functional  hierarchy  will  be  updated  to  depict 
the  overall  actions  required  to  effectively  and  efficiently  meet  the  threat  detailed  in  the 
problem  statement.  As  discussed  earlier,  this  functional  hierarchy  is  notional  and  will 
change  as  the  team  further  defines  the  scope  of  the  project. 
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Figure  A-4.  ASBMD  Functional  Hierarchy  (Notional) 

2.2.4  Analysis  of  Alternatives 

Upon  completion  of  the  problem  formulation  and  the  functional  architecture 
determination  described  above,  our  team  will  determine  the  physical  architectures  and 
generate  various  system  alternatives.  During  this  phase,  the  team  will  also  begin 
developing  the  models  that  will  be  used  to  analyze  the  various  alternatives  of  the  system. 
This  work  will  help  drive  the  feasibility  analysis  and  metrics  that  will  be  used  in  the 
justification  for  a  final  recommended  decision. 

2.2.4.1  Developing  Alternatives 

Morphological  charts  and  the  QFD  diagrams  created  earlier  will  be  used  to  assist 
the  project  team  in  the  development  of  alternatives.  This  is  the  point  in  the  process  where 
the  “what’s”  are  developed  into  “how’s.” 
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2.2.4.2  Generate  Metrics  to  Measure  Effectiveness/Performance 

During  this  activity,  the  team  will  be  generating  metrics  as  we  compare  the 
alternative  systems  defined  during  the  Analysis  of  Alternatives  phase  to  both  the 
operational-  and  performance-related  requirements.  The  objective  of  the  developed 
metrics  will  be  to  provide  quantitative  evaluation  of  the  effectiveness  and  performance  of 
the  various  alternatives.  The  outcome  of  this  effort  will  be  a  measurement  of  how 
completely  each  of  the  alternatives  meets  the  defined  performance  requirements. 

2.2.4.3  Develop  Models  and  Simulations 

During  this  task,  the  team  will  develop  models  and  simulations  using  different 
modeling  techniques  for  the  purpose  of  evaluating  tangible  alternatives  and  as  a  method 
of  understanding  the  system  of  systems,  functional  decomposition,  hierarchy,  and  overall 
system  effectiveness.  Furthermore,  Arena,  Excel,  MATLAB,  UML  and  other  tools  will 
be  used  throughout  the  design  process  to  assess  risk,  cost,  schedule,  and  system 
performance.  The  goal  is  to  produce  a  system  architecture  that  can  provide  a  solution  to 
the  problem  statement  that  best  meets  the  needs  identified  from  the  stakeholder  analysis. 

2.2.5  System  Concept  Refinement/Finalization 

The  final  phase  of  our  modified  SEP  is  to  perform  System  Concept  Refinement 
and  Finalization  activities.  The  goal  for  this  phase  is  to  carry  out  the  final  decision 
analysis  of  the  alternatives  with  reference  to  the  Measures  of  Effectiveness  (MOEs)  and 
Measures  of  Performance  (MOPs)  obtained  from  metrics  analysis  and  the  modeling  and 
simulation  exercises.  It  will  involve  cost  analysis,  risk  analysis,  sensitivity  analysis, 
trade-off  study,  and  finally,  the  recommendation  of  the  preferred  alternatives. 

2.2.5.1  Cost  Analysis 

The  goal  for  cost  analysis  is  to  estimate  the  total  Life  Cycle  Cost  (LCC),  or  Total 
Ownership  Cost  (TOC),  of  the  various  identified  alternative  systems.  The  LCC  is  defined 
as  the  cost  of  the  Research,  Development,  Test,  and  Evaluation  (RDT&E);  procurement 
of  prime  equipment,  support  equipment  and  spares;  operations  and  support  of  prime 
equipment,  support  equipment  and  spares;  and  disposal  of  the  system.  Out  year  costs  will 
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be  discounted  to  reflect  the  declining  value  of  the  dollar  over  time  and  allow  alternatives 
to  be  compared  to  one  another  using  net  present  value. 

2.2.5.2  Risk  Analysis 

Risk  analysis  will  be  conducted  to  identify  the  risk  drivers  associated  with 
developing  this  Capstone  project.  The  goal  is  to  identify  cost,  schedule,  and  technical 
risks  so  that  they  can  be  controlled,  and  that  the  consequences  of  courses  of  action  can  be 
determined  as  early  in  the  process  as  possible.  The  ASBMD  team  will  perform  this  risk 
management  during  all  phases  of  the  development  of  our  project.  All  risks  that  we 
identify  will  be  analyzed  and  scored  according  to  risk  management  procedures  defined  in 
the  DoD  Risk  Management  Guide  (RMG).  All  risks  are  evaluated  and  categorized 
according  to  the  probability  (likelihood)  of  failing  to  achieve  a  particular  outcome  and  the 
consequences  (impact)  of  failing  to  achieve  that  outcome. 

Initial  risk  analysis  performed  by  the  ASBMD  team  has  identified  six  current 
risks.  Four  of  these  risks  are  related  to  meeting  our  project  schedule  and  two  are  related 
to  being  able  to  find  a  feasible  technical  solution.  An  Excel  spreadsheet  is  maintained  by 
the  team  and  contains  a  current  status  of  all  risks  being  tracked  by  the  team  and  the 
mitigation  plans  for  each  one.  Figure  A- 5  shows  the  current  risk  matrix  for  the  ASBMD 
team. 


Figure  A-5.  Current  ASBMD  Risk  Management  Matrix 
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Table  A-2  describes  the  risks  currently  being  tracked  by  the  team. 

Table  A-2.  Current  Risk  Description  for  ASBMD 


Risk# 

Description 

Type 

1 

The  team  will  not  be  able  to  generate  a  list  of  viable  alternatives  to 
counter  the  threat  in  a  timely  manner,  so  the  analysis  of  alternatives 
will  be  delayed. 

Schedule 

2 

The  team  will  not  decide  on  a  list  of  Key  Performance  Parameters 
(KPPs)  in  a  timely  manner,  so  the  analysis  of  alternatives  will  be 
delayed. 

Schedule 

3 

Modeling  and  simulation  tools  will  not  be  developed  in  time  for 
their  use  in  the  analysis  of  alternatives. 

Schedule 

4 

Final  project  report  and  briefing  will  not  be  completed  on  time. 

Schedule 

5 

The  team  will  not  be  able  to  find  a  feasible  solution  to  meet  the 
stated  need. 

Technical 

6 

The  chosen  solution  is  not  able  to  be  integrated  with  existing 
systems. 

Technical 

2.2.5.3  Sensitivity  Analysis 

A  basic  sensitivity  analysis  will  be  conducted  to  verify  the  quality  of  the 
mathematical  models.  The  assigned  weights  used  for  decision-making  criteria  will  be 
varied  to  determine  the  areas  that  are  the  most  influential  in  the  outcome  of  the  system 
decision.  Sensitivity  analysis  will  identify  the  sources  of  uncertainty  that  affect  the 
study's  conclusions  most.  This  will  ensure  the  quality  of  the  models  and  increase 
confidence  in  the  assessment. 

2.2.5.4  Trade-off  Study 

A  trade-off  study  is  the  activity  of  finding  the  solution  to  a  problem  that  best 
satisfies  a  series  of  technical  measures  and/or  cost  functions.  These  measures  will 
describe  the  desirable  characteristics  of  a  given  solution.  Multiple  Criteria  Decision 
Making  (MCDM)  methodology  such  as  min-max  methods,  min-max  regret  methods,  and 
weighting  methods  (decision  matrix),  may  be  used  to  compare  each  of  the  alternatives. 
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3  MILESTONES  AND  DELIVERABLES 


3.1  OVERVIEW 

As  described  above,  when  using  the  SEP  approach  there  are  several  key 
milestones  and  associated  deliveries  that  the  team  will  need  to  make  to  ensure  that 
progress  is  being  made.  As  detailed  in  section  2.2,  this  project  will  focus  on  the  Concept 
Refinement  Phase  of  the  Defense  Acquisition  Process.  The  ASBMD  team  will  create 
high  level  excerpts  from  each  of  the  key  documents  identified  in  the  Integrated  Defense 
Acquisition,  Technology,  and  Logistics  Life  Cycle  Management  Evolutionary 
Acquisition  Program,  using  the  DoD  Instruction  5000.2  as  the  guide.  The  high  level  view 
of  the  Defense  Acquisition  Process  focusing  on  the  areas  that  we  are  going  to  address  is 
shown  below  in  Figure  A-6. 

User  Needs  & 

Technology  Opportunities 


/  |  \ 


Figure  A-6.  ASBMD  Focus  within  the  Defense  Acquisition  Process 
[Lifecycle  Framework  View] 

3.2  DELIVERABLES 

The  following  products  will  be  provided  by  the  ASBMD  team  for  this  Capstone 
project  as  a  stand-alone  document  as  well  as  being  excerpted  in  the  team’s  final  report: 

•  Problem  Statement:  Statement  outlining  the  current  system  capabilities  and 
threat  assessments;  provides  details  of  the  current  system  functional  gap  that 
our  team  has  chosen  to  address. 
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•  Project  Management  Plan  (PMP):  Initial  project  guide  that  will  shape  our 
teams  approach  and  schedule  for  developing  the  project  documentation. 

•  Stakeholder  Analysis:  Results  from  the  QFD  and/or  Pareto  Analysis. 

•  CONOPS  (Excerpt):  Describes  the  concept  of  operations  for  our  project; 
also,  the  beginning  of  how  we  plan  to  fit  our  solution  into  the  existing  systems 
within  the  fleet. 

•  Functional  Area  Analysis:  Identification  of  operational  tasks,  conditions,  and 
standards  needed  to  accomplish  the  system  objectives. 

•  Functional  Architecture  (Department  of  Defense  Architecture 
Framework  [DoDAF]  products):  High-level  functional  diagrams  depicting 
the  overall  system  alignment  and  functions  from  a  system  view.  Also,  details 
interactions  within  the  system  and  identifies  the  key  functions  that  are 
performed. 

•  Initial  Capabilities  Document  (ICD)  (Excerpt):  As  defined  in  the  Chairman 
of  the  Joint  Chiefs  of  Staff  Instruction  (CJCSI)  3 170.0  IF,  Joint  Capabilities 
Integration  and  Development  System  (JCIDS).  This  will  be  the  main 
deliverable  for  the  system  engineering  effort  of  our  project.  The  ICD  will  be 
used  to  identify  the  KPPs  and  Key  System  Attributes  (KSAs)  which  define  the 
most  critical  elements  of  performance  for  our  system.  This  document  will  be 
closely  tied  to  the  CONOPS;  this  is  done  to  ensure  that  the  KPPs  identified 
meet  the  overall  need  of  the  system  as  originally  defined  during  the  analysis 
phase. 

•  Analysis  of  Alternatives  Results:  These  will  be  used  to  evaluate  each  of  the 
possible  system  combinations.  This  analysis  will  take  into  account  the  ability 
of  the  alternatives  to  meet  KPPs  and  KSAs  as  well  as  affordability  and 
schedule  constraints. 

•  Metrics,  Models  and  Simulation  Analysis:  Used  to  detail  the  models  and 
associated  metrics  that  will  be  used  to  validate  the  chosen  systems 
performance  to  ensure  it  meets  MOEs  and  KPPs. 
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•  Final  Report:  Collection  of  the  artifacts  that  were  delivered  earlier  in  the 
project.  The  final  report  will  be  the  documentation  of  the  final  process  and 
schedule  that  the  team  used  to  assess  and  present  the  recommended  system 
architecture. 

3.3  SCHEDULE 

The  overall  schedule  for  the  analysis  and  delivery  of  the  key  work  products  is 
outlined  in  Figure  A-7. 


Figure  A-7.  ASBMD  Current  Project  Schedule 
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1  ANTI-SHIP  BALLISTIC  MISSILE  DEFENSE  CONOPS 

1.1  Objective 

The  objective  of  the  Anti-Ship  Ballistic  Missile  Defense  (ASBMD)  system  is  to 
detect,  track  and  eliminate  Anti-Ship  Ballistic  Missile  (ASBM)  threats.  The  team  will 
research  and  document  a  proposed  architecture  for  a  total  system  solution  that  could 
potentially  be  used  to  combat  the  evolving  ASBM  threats. 

1.2  Assumptions 

The  following  list  of  assumptions  will  apply  to  this  document  and  all  follow-on 
efforts  for  this  project: 

•  ASBM  threats  will  be  launched  from  land. 

•  All  current  communication  mechanisms  are  operational  and  deployed  on  all 
systems. 

•  While  used  for  Ballistic  Missile  Defense  (BMD),  the  system  will  not  be 
required  for  additional  functions. 

1.3  Scope 

This  document  outlines  the  ASBMD  Concept  of  Operations  (CONOPS)  for 
support  of  the  Team  1  Master  of  Science  in  Systems  Engineering  (MSSE)  Capstone 
project.  The  system  under  investigation  is  limited  to  the  specific  scope  that  has  been 
defined  in  the  problem  statement  and  detailed  in  the  Project  Management  Plan  (PMP) 
created  earlier  in  the  project.  The  scope  of  the  project  includes  the  research,  creation  and 
documentation  of  the  total  system  architecture  that  may  be  used  to  combat  the  identified 
threats.  The  system  is  limited  both  by  the  assumptions  outlined  in  Section  1.2  and  by  the 
constraint  that  it  must  communicate  and  integrate  into  the  existing  Ballistic  Missile 
Defense  System  (BMDS). 

Due  to  the  maturity  of  existing  capabilities  to  detect  and  track  ballistic  missiles 
during  the  boost  phase,  the  ASBMD  team  will  primarily  focus  the  detailed  analysis  and 
architecture  documentation  on  the  post-boost  phase  -  tracking  and  eliminating  the  threats 
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during  later  phases  of  the  ballistic  flight-path.  Figure  B-l  depicts  the  basic  stages  of  flight 
of  a  nominal  ballistic  missile. 


Figure  B-l.  Phases  of  Ballistic  Missile  Flight 
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2  SYSTEM  NEED 


2.1  Problem  Statement 

Recent  intelligence  reports  have  suggested,  as  described  recently  in  U.S.  Naval 
Institute ’s  Proceedings  Magazine,  that  multiple  nations  are  developing  ballistic  missiles 
that  can  be  used  against  moving  targets,  such  as  ships.  These  threats  are  being 
increasingly  characterized  as  having  the  ability  to  maneuver  for  evasion  and  to  track  their 
targets  during  the  terminal  phase  of  the  ballistic  missile  flight  path,  as  depicted  in 
Figure  B-2.  One  such  technology  is  said  to  be  able  to  cover  a  range  of  2,000  kilometers 
(km)  and  operate  at  a  speed  of  Mach  10.  This  type  of  threat  could  greatly  impact  the 
current  CONOPS  of  U.S.  Navy  ships.  While  there  are  currently  BMD  solutions  that  can 
intercept  threats  in  the  midcourse  and  terminal  phases,  no  comprehensive  system  has 
been  developed  to  counter  a  maneuvering  reentry  vehicle  threat  post-launch.  Figure  B-3 
demonstrates  the  potential  range  for  these  threats  if  launched  from  mainland  China. 


launch  site 


carrier  when  the 
missile  was  launched) 


of  the  aircraft 
carrier  with  mill 
segment  guidance} 


Figure  B-2.  Notional  Operation  of  ASBM  Threat 
with  Maneuvering  Reentry  Vehicle 
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Figure  B-3.  Map  of  China  and  Overlay  of  Missile  Ranges 
2.2  The  Ballistic  Missile  Flight 

Intercepting  a  missile  in  its  boost  phase  is  the  ideal  solution  for  ballistic  missile 
defense.  If  the  missile  is  carrying  a  chemical,  biological,  or  nuclear  weapon,  the  debris 
will  most  likely  fall  on  the  country  that  launched  the  missile.  At  the  least,  it  will  certainly 
not  have  obtained  enough  velocity  to  reach  its  intended  target.  Because  of  this,  it  is  not 
critical  to  completely  destroy  the  missile’s  warhead.  Although  attacking  a  missile  while  it 
is  struggling  against  the  earth’s  gravity  is  ideal,  it  poses  significant  challenges  to  a 
defense  system.  First,  the  boost  phase  is  relatively  short.  This  means  that  sensors  will 
have  to  detect  a  launch  and  relay  accurate  information  about  the  missile  very  quickly. 
Second,  an  interceptor  missile  would  have  to  be  very  close,  or  extremely  fast  to  catch  up 
to  the  accelerating  missile,  and  properly  configured  to  intercept  a  target  in  the  boost 
phase.  When  possible,  for  the  global  coverage  and  protection  against  more  lethal 
payloads  it  can  provide,  a  capability  to  intercept  a  missile  near  its  launch  point  is  always 
preferable  to  attempting  to  intercept  that  same  missile  closer  to  its  target. 

The  midcourse  phase  allows  the  largest  opportunity  to  intercept  an  incoming 
missile.  At  this  point,  the  missile  has  stopped  thrusting,  so  it  follows  a  more  predictable 

path.  Depending  on  the  interceptor  launch  location,  multiple  interceptors  could  be 
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launched,  with  a  delay  between  them  to  see  if  the  first  ones  were  successful.  Since  the 
interceptor  has  a  longer  time  to  engage,  fewer  interceptor  sites  are  needed  to  defend 
larger  areas.  Unfortunately,  a  longer  period  in  space  provides  an  attacking  missile  the 
opportunity  to  deploy  countermeasures  against  a  defensive  system.  However,  the 
defensive  system  also  has  more  time  to  observe  and  discriminate  countermeasures  from 
the  warhead. 

The  terminal  phase  of  a  ballistic  missile’s  flight  is  normally  less  than  one  minute 
long.  At  this  point,  defensive  systems  must  be  very  close  to  the  missile’s  target  in  order  to 
defend  against  the  attack.  Countermeasures  are  less  of  a  challenge  in  this  phase.  They 
usually  fall  slower  than  the  warhead  and  are  burned  up  as  the  warhead  re-enters  the 
atmosphere.  Defensive  systems  designed  for  the  terminal  phase  are  most  effective  in 
protecting  nearby  troop  concentrations,  ports,  airfields,  and  staging  areas.  Currently 
fielded  terminal  phase  interceptors  have  not  been  proven  to  be  effective  against 
maneuvering  re-entry  vehicles. 

2.3  Existing  Capabilities 

There  are  currently  multiple  systems  deployed  that  are  designed  to  combat 
Theater  Ballistic  Missiles.  Each  of  the  individual  systems  are  designed  to  focus  on 
specific  phases  of  the  ballistic  missile  flight  as  described  in  section  2.2.  Some  examples 
of  these  systems  and  their  primary  functions  are  described  in  Table  B-l  below. 
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Table  B-l.  Existing  Systems,  Time  Phase,  and  Function 


System  Name 

Phase 

Function 

Weapon  Systems 

Ground  Based  Interceptor  (GBI) 

Midcourse 

Engagement 

Patriot  Advanced  Capability-3  (PAC-3) 

Boost/Midcourse 

Engagement 

Standard  Missile  (SM)-3  Block  IA 

Midcourse 

Engagement 

SM-2  Block  IVA  (SMT) 

Terminal 

Engagement 

Terminal  High  Altitude  Area  Defense 
(THAAD) 

Terminal 

Engagement 

Sensors 

Cobra  Dane  Radar 

Boost 

Detection/Tracking 

Ultra  Early  Warning  Radar  (UEWR) 

Boost 

Detection/Tracking 

AN/TP Y-2  (Forward-Based  Mode) 

Boost 

Detection/Tracking 

AN/TPY-2  (THAAD  Mode) 

Terminal 

Detection/Tracking 

AN/SPY- 1 

Midcourse/T  erminal 

Detection/Tracking 

Space-Based  Sensor  Suite 

Boost/Midcourse 

Detection/Tracking 

Sea-based  X-band  Radar  (SBX) 

Boost/Midcourse 

Detection/Tracking 

BM  C4I 

Command  and  Control,  Battle 

Management  and  Communications 
(C2BMC)  Spiral  6.2 

All 

BMC4I 

A  specific  example  of  such  a  system  includes  the  successful  Aegis  BMD  System. 
This  specific  system  uses  both  remote  and  local  detection  and  tracking  via  ground  and 
satellite  based  sensor  systems  and  shipboard  sensors.  Once  the  threat  has  been  detected 
and  transitioned  to  track,  the  remote  systems  can  “hand  over”  the  threat  track  to  the 
shipboard  AN/SPY- ID  Radar  System  for  organic  tracking  and  engagement.  The 
handover  of  the  threat  is  accomplished  by  having  the  remote  tracking  system  calculate  a 
flight  trajectory  of  the  threat  track  and  cue  the  organic  radar  to  a  point  in  space  where  the 
threat  will  be  at  a  given  time.  This  method  requires  direct  high  speed  communication 
between  all  elements  in  the  system.  The  Aegis  BMD  systems  also  rely  heavily  on  the 
availability  of  the  SM-3  or  SM-2-Block  IVA  missile  to  engage  and  destroy  ballistic 
targets  in  the  midcourse  and  terminal  phases,  respectively.  The  systems  currently  have  no 
alternate  or  complementary  shipboard  weapons  that  could  be  used  to  combat  a  ballistic 
threat. 
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System  Configuration  —  2007 
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Figure  B-4.  Missile  Defense  Agency  (MDA)  Ballistic  Missile  Defense  System, 

as  of  2007 

As  discussed  earlier  in  this  document,  there  are  multiple  systems  currently 
deployed  or  in  development  that  have  the  ability  to  detect  and  track  ballistic  missiles 
during  boost,  midcourse,  and  terminal  phases.  Coupled  with  the  existing  system  that 
provides  the  capability  to  engage  these  threats  during  the  same  phases,  the  U.S.  has  a 
robust  system  design  that  has  a  successful  track  record  during  test  intercepts  of  ballistic 
targets. 
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3  SYSTEM  JUSTIFICATION 

3.1  Current  System  Shortcomings 

3.1.1  Sensors 

As  previously  described,  the  current  BMDS  rely  heavily  on  the  ability  of  remote, 
internal,  and  onboard  sensors  to  predict  and  relay  the  flight  path  trajectory  of  the  ballistic 
threat.  The  anti-ship  threats  that  are  being  introduced  have  uncovered  a  major  shortfall  in 
the  current  deployed  systems.  Using  the  example  threat  given  in  the  problem  statement, 
upon  re-entry  the  threat  can  be  traveling  in  excess  of  Mach  10  and  can  maneuver  during 
the  terminal  portion  of  flight,  altering  its  aim-point  and  ultimately  forcing  a  defense 
system  to  estimate  a  false  trajectory.  Given  the  current  capabilities,  the  ability  of  the 
system  to  predict  the  flight  path  of  these  threats  becomes  impossible. 

3.1.2  Weapon  System 

Another  shortcoming  of  the  current  system  is  that,  for  sea-based  intercepts,  it 
relies  exclusively  on  the  availability  of  ships  configured  with  the  Aegis  BMD  Weapon 
System  and  loaded  with  SM-3  or  SM-T  missiles.  Only  5  cruisers  and  16  destroyers  are 
configured  to  conduct  Aegis  BMD  missions,  so  these  assets  must  be  strategically  located 
to  provide  adequate  coverage.  While  the  SM-3  Block  IA  is  a  full  rate  production  missile, 
it  is  only  capable  of  conducting  midcourse  intercepts.  The  Sea-Based  Terminal  (SBT) 
terminal-phase  intercept  capability  is  provided  by  use  of  the  modified  SM-T.  Since  this 
missile  is  no  longer  in  production,  the  SBT  capability  is  limited  to  the  remaining 
inventory  of  this  missile.  Given  the  minimal  system  availability,  there  exists  a  very  large 
operational  risk  for  most  carrier  battle  groups.  Based  on  the  capabilities  deployed  to-date, 
if  the  threats  that  we  have  identified  are  put  into  production,  there  would  need  to  be  a 
very  large  shift  in  the  current  operational  CONOPS  for  the  U.S.  Navy.  Without  a  robust 
and  reliable  system  to  counter  these  threats,  U.S.  Navy  Carrier  Ships  would  be  required 
to  drastically  reduce  their  ability  to  operate  within  close  vicinity  of  countries  that  have  the 
threat  production  capabilities. 
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3.2  New  System  Benefits 

The  system  architecture  that  the  ASBMD  team  will  be  producing  will  document  a 
system  that  will  eliminate  the  ASBMD  threat  by  using  remote  data  for  tracking  and 
engagements.  The  specific  benefits  of  the  ASBMD  System  will  be  its  ability  to  track  and 
eliminate  or  avoid  maneuvering  threats  during  the  midcourse  or  terminal  phases  of  flight. 
The  Navy  will  benefit  from  a  robust  architecture  that  can  provide  engagement-quality 
data  to  a  system  that  can  be  used  to  eliminate  the  threat  during  the  terminal  phase  of 
flight. 

3.3  Priority  of  New  Features 

The  ASBMD  team  has  prioritized  the  key  system  features  taking  into 
consideration  existing  systems  that  can  perform  portions  of  the  mission.  As  stated  earlier, 
there  are  multiple  systems  that  have  the  ability  to  detect  and  engage  ballistic  missiles 
during  the  boost  phase  of  ballistic  missile  flight,  therefore  the  priority  of  our  proposed 
system  and  analysis  will  be  the  tracking  and  engagement  of  anti-ship  ballistic  missiles 
during  the  midcourse  and  terminal  phase  of  flight. 

Within  the  terminal  phase  of  flight  there  are  two  key  features,  tracking  and 
engagement,  and  we  have  prioritized  these  functions  as  well.  The  ASBMD  team 
prioritized  tracking  of  the  re-entry  vehicles  as  the  highest  priority  and  then  the 
engagement  of  the  threats  as  the  second  highest.  This  prioritization  is  based  on  the  fact 
that  the  ASBMD  System  is  predicated  on  the  ability  of  the  system  to  provide  engagement 
quality  data  that  may  be  used  to  engage  and  eliminate  the  threats;  therefore,  tracking  of 
the  threats  is  of  the  utmost  importance. 


128 


Appendix  B 


4  FUNCTIONAL  REQUIREMENTS 

Discussions  with  stakeholders  resulted  in  high  level  operational  requirements  that 
will  be  used  as  a  starting  point  for  further  analysis  and  decomposition.  The  list  is  subject 
to  change  as  feedback  is  generated  in  subsequent  systems  engineering  steps.  A  complete 
final  list  will  be  documented  in  the  ASBMD  Initial  Capabilities  Document  (ICD). 

1)  ASBMD  System  shall  be  capable  of  sending,  receiving,  and  processing 
intelligence  reporting  messages  to  be  used  for  situational  awareness  related  to 
Ballistic  Missile  flight  path.  (Includes  but  not  limited  to  the  ability  to  receive 
and  process  Global  Command  and  Control  System  Maritime  (GCCSM),  Link- 
16  Tactical  Digital  Information  Link  (TADIL-J),  N-Series  Messages,  and 
J-Series  Messages). 

2)  ASBMD  System  shall  process  received  intelligence  messages  and  create  radar 
search  sectors  to  be  used  by  both  on-board  and  off-board  sensors. 

3)  ASBMD  System  shall  detect  and  track  Ballistic  Missiles  including  up  to 

10  vehicles  during  terminal  phase  of  missile  flight  path.  Tracking  shall  include 
the  production  and  dissemination  of  engagement  quality  data. 

4)  ASBMD  System  shall  be  capable  of  near  simultaneous  engagement  of  no- 
less-than  10  ballistic  vehicles. 

5)  ASBMD  System  shall  be  capable  of  performing  “Launch  on  Remote”  using 
fire  control  quality  data  from  the  BMDS  network. 

6)  ASBMD  System  shall  have  the  ability  to  perform  both  self-defense  and  BMD 
missions. 

7)  ASBMD  System  shall  have  a  Mean  Time  Between  Failures  (MTBF)  that  is 
greater  than  or  equal  to  the  MTBF  of  the  existing  BMDS  System. 

8)  ASBMD  System  shall  have  the  ability  to  perform  high  fidelity  object 
discrimination. 
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9)  ASBMD  System  shall  have  the  ability  to  perform  localization. 

10)  ASBMD  System  shall  have  the  capability  to  perform  threat  identification. 

4.1  Mission  Features  Capabilities  and  Functions 

4.1.1  System  Components  and  Functions 

The  ASBMD  capability  will  be  achieved  by  a  system  of  systems  that,  to  meet  its 
mission  requirements,  is  comprised  of  a  minimum  set  of  components.  Components  that 
will  be  considered  and  analyzed  may  include:  radar,  electro-optic  (EO)/inffared  (IR) 
sensors,  passive  electronic  warfare  sensors,  communications/link  architecture,  command 
and  control,  decoys,  electronic  countermeasures,  and  weapon  system. 

A  preliminary  functional  analysis  has  resulted  in  a  list  of  the  primary  system 
functions,  as  follows: 


•  Search:  The  system  will  be  capable  of  conducting  search  functions  in 
self-defense  and  BMD  modes. 

•  Detect:  The  system  will  be  capable  of  detecting  an  incoming  threat 
organically  (using  own-ship  sensors).  The  system  will  also  be  capable  of 
initiating  engagement  sequences  based  on  remote  sensor  detection  and  hand- 
off  of  track. 

•  Acquire  Track:  The  system  will  be  capable  of  conducting  organic  track 
acquisition  and  communicating  that  track  to  the  BMDS.  The  system  will  also 
be  capable  of  a  launch  on  remote  track  data,  with  eventual  acquisition  of  the 
track  organically,  or  full  engagement  on  remote  track  data  (with  no  organic 
track  acquisition). 

•  Planning:  The  system  will  be  capable  of  communicating  with  BMDS 
resources  for  determination  of  the  best  use  of  local  radar  and  weapon 
resources. 

•  Identification:  The  system  will  be  capable  of  identifying  the  threat  type  and 
not  engage  on  countermeasures,  within  margin,  via  onboard  sensor 
discrimination. 

•  Engagement:  The  system  will  be  capable  of  executing  an  engagement  against 
the  incoming  threat. 
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•  Kill  Assessment:  The  system  will  provide  kill  assessment  data  to  the  operator 
and  the  BMDS  so  that  a  determination  of  kill  and  potential  for  re-engagement 
can  be  assessed. 

4.1.2  Operational  Environment 

The  system  must  be  capable  of  surviving  and  operating  in  the  tactical 
environment  and  will  meet  all  requirements  for  system  certification  and  fielding.  Ships 
with  this  capability  can  be  deployed  in  any  operational  area  necessary  to  provide 
coverage  in  the  ASBMD  mission  area. 

4.1.3  System  Interfaces 

The  system,  as  designed,  must  interface  with  the  larger  BMDS  for  the  purposes  of 
battle  management,  data  sharing,  and  command  and  control.  It  will  interface  with  its 
battlegroup  or  ships  in  company  for  local  and  remote  fire  control,  radar  resource  and 
weapon  management. 
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5  CONCLUSIONS 

Currently  there  is  no  single  solution  to  address  the  threat  described  in  the  problem 
statement.  In  designing  a  system  of  systems  solution,  a  key  objective  of  this  project  will 
be  to  consider  technologies  that  would  complement  a  layered  approach  that  takes 
advantage  of  remote  and  forward-based  capabilities  as  well  as  organic/own-ship 
capabilities.  Any  leveraging  of  existing  technology  will  require  that  the  systems  are  made 
more  robust  to  meet  requirements  for  sensor  function,  detection,  and  BMDS  interfaces. 
The  final  product  of  the  system  design  will  be  to  propose  a  reliable,  compatible,  and 
interoperable  ASBMD  functionality  to  support  defense  of  critical  assets  and  mission 
areas  to  the  U.S.  Navy. 
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ABBREVIATIONS  AND  ACRONYMS 


ASBM 

Anti-Ship  Ballistic  Missile 

ASBMD 

Anti-Ship  Ballistic  Missile  Defense 

BMDS 

Ballistic  Missile  Defense  System 

C2 

Command  and  Control 

CONOPS 

Concept  of  Operations 

GCCSM 

Global  Command  and  Control  System  Maritime 

ICD 

Initial  Capabilities  Document 

ID 

Identification 

KA 

Kill  Assessment 

LOR 

Launch  on  Remote 

MOE 

Measures  of  Effectiveness 

MOP 

Measures  of  Performance 

MTBF 

Mean  Time  Between  Failures 

SATCOM 

Satellite  Communication 

TADIL-J 

Tactical  Digital  Information  Link 
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1  SCOPE 

The  proposed  Anti-Ship  Ballistic  Missile  Defense  (ASBMD)  System  is  scoped  to  be  a 
system  of  systems  that  provides  a  set  of  value-added  functions  that  will  be  operated  within  the 
existing  Ballistic  Missile  Defense  System  (BMDS).  The  system’s  objective  is  to  provide 
increased  capabilities  to  defend  against  and  eliminate  Anti-Ship  Ballistic  Missile  (ASBM) 
threats.  The  proposed  system  will  be  fully  integrated,  interrelated,  and  interoperable  with  the 
existing  BMDS.  As  a  result,  the  ASBMD  System  will  be  an  information  environment  within  an 
existing  combat  system  comprised  of  interoperable  computing  and  communication  components. 
As  originally  defined  in  the  ASBMD  Concept  of  Operations  (CONOPS),  the  ability  of  an  ASBM 
threat  to  maneuver  during  its  terminal  phase  of  flight  is  what  differentiates  it  from  the  average 
ballistic  missile.  Due  to  the  distinct  operational  attributes  of  the  ASBM  threat,  the  unique 
functionality  of  the  ASBMD  System  will  be  limited  to  the  tracking  and  elimination  of  these 
threats  during  the  post-boost  phase  of  flight.  Although  the  threats  will  be  tracked  throughout 
their  flight  by  remote  and  onboard  sensors,  the  engagement  of  the  threats  will  not  occur  until 
post-boost  phase. 
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2  NOTIONAL  ARCHITECTURE 


Figure  C-l  depicts  the  high  level  notional  architecture  of  the  ASBMD  System  that  will  be 
used  to  eliminate  the  defined  threats.  Each  of  the  key  functions  identified  will  be  discussed  in 
detail  in  later  sections  of  this  document. 


Figure  C-l.  Notional  Functional  Diagram 
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3  GENERATION  OF  SYSTEM  REQUIREMENTS 

Figure  C-2  depicts  the  general  flow  that  was  used  to  create  the  high-level  functional 
requirements,  Measures  of  Effectiveness  (MOEs),  and  Measures  of  Performance  (MOPs)  for  the 
ASBMD  System.  As  depicted,  the  process  began  with  definition  of  the  initial  needs  statement; 
the  team  then  created  a  general  set  of  system  requirements  to  address  the  capabilities  that  a 
system  would  need  to  fulfill  in  order  to  address  the  needs  statement.  The  next  step  was  to  create 
a  CONOPS  to  help  bound  the  high-level  system  requirements  in  an  operational  context,  which 
leads  directly  into  development  of  MOEs  and  MOPs  for  the  system.  Each  of  these  products  is 
identified  below. 


Figure  C-2.  Requirements  Generation  Process  Flow 
3.1  Functional  Requirements 

The  following  is  a  list  of  high-level  functional  requirements  that  was  used  to  perform  the 
follow-on  system  analysis  and  decomposition  into  the  functional  architecture  shown  in 
Figure  C-l.  This  is  an  excerpted  list  of  requirements  provided  as  part  of  the  CONOPS,  and 
should  not  be  viewed  as  a  complete  list  of  requirements  that  the  system  must  meet. 

1)  ASBMD  System  shall  be  capable  of  sending,  receiving,  and  processing  intelligence 
reporting  messages  to  be  used  for  situational  awareness  related  to  Ballistic  Missile 
flight  path.  (Includes,  but  is  not  limited  to,  the  ability  to  receive  and  process  Global 
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Command  and  Control  System  Maritime  [GCCSM],  Link-16  Tactical  Digital 
Information  Link  [TADIL-J],  N-Series  messages,  and  J-Series  messages) 

2)  ASBMD  System  shall  process  received  intelligence  messages  and  create  radar  search 
sectors  to  be  used  by  both  on-board  and  off-board  sensors. 

3)  ASBMD  System  shall  track  ballistic  missiles  including  no  less  than  10  vehicles 
during  midcourse  and/or  terminal  phase  of  missile  flight  path.  Tracking  shall  include 
the  production  and  dissemination  of  engagement  quality  data. 

4)  ASBMD  System  shall  be  capable  of  near  simultaneous  engagement  of  no-less-than  2 
ballistic  vehicles. 

5)  ASBMD  System  shall  be  capable  of  performing  launch  on  remote  using  fire  control 
quality  data  from  the  BMDS  network. 

6)  ASBMD  System  shall  have  the  ability  to  perform  both  self-defense  and  Ballistic 
Missile  Defense  (BMD)  missions. 

7)  ASBMD  System  shall  have  a  Mean  Time  Between  Failures  (MTBF)  that  is  greater 
than  or  equal  to  the  MTBF  of  the  existing  BMDS  architecture  into  which  the  ASBMD 
System  has  been  integrated. 

8)  ASBMD  System  shall  have  the  ability  to  perform  high  fidelity  object  discrimination. 

9)  ASBMD  System  shall  have  the  ability  to  perform  localization. 

10)  ASBMD  System  shall  have  the  capability  to  perform  threat  identification. 

3.2  MOEs  and  MOPs 

The  key  ASBMD  System  MOEs  and  MOPs  are  identified  below.  As  with  the  System 
Requirements  before,  these  lists  should  not  be  considered  complete,  since  they  are  meant  to  be 
excerpts  that  were  used  to  help  bound  the  system. 

3.2.1  MOEs 

1)  Probability  of  detection 

2)  Probability  of  false  alarm 

3 )  Probability  of  kill 

4)  Probability  of  correct  identification 

5)  Probability  of  correct  discrimination 
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6)  Maximum  number  of  targets  engaged 

7)  Probability  of  information  exchange 

8)  Maximum  number  of  targets  simultaneously  tracked 

3.2.2  MOPs 

1)  Track  formulation  time 

2)  Organic  detection  time 

3)  Mean  time  to  discriminate 

4)  Engagement  time 

5)  Re-engagement  time 

6)  Time  to  conduct  kill  assessment 

7)  Number  of  simultaneous  engagements 

8)  Number  of  non-detections 
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4  CAPABILITIES  AND  FUNCTIONAL  DECOMPOSITION 

As  originally  depicted  in  Figure  C-l,  the  notional  functional  decomposition  contains  key 
functions  that  are  needed  to  ensure  that  the  ASBMD  System  can  meet  its  key  mission 
requirements.  This  section  of  the  Initial  Capabilities  Document  (ICD)  will  decompose  each  of 
the  high  level  functions  to  a  lower  level  which  will  allow  easier  and  more  detailed  mapping  of 
each  function  to  the  defined  functional  requirements.  A  basic  definition  of  each  high-level 
function  is  provided  below.  The  definition  will  help  frame  the  expectations  and  flow  of  each  of 
the  decomposition  diagrams. 

4.1  System  Components  and  Functions 

The  key  system  components  and  functions  are  defined  below. 
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4.1.1  Search 

The  basic  flow  of  the  Search  function  is  depicted  in  Figure  C-3,  and  is  started  upon  the 
receipt  of  a  queuing  signal  from  either  an  off-board  source  (BMDS)  or  the  human  operator.  The 
queuing  parameters  are  then  converted  to  radar  parameters  that  are  used  to  build  the  sector  of 
space  that  will  be  searched.  After  calculation  of  the  radar  parameters  and  required  resources,  the 
system  will  then  evaluate  the  ability  to  perform  the  requested  search  function  with  organic 
resources.  At  this  point  in  the  functional  flow  the  system  will  take  one  of  two  actions,  either  it 
will  determine  organic  resources  are  available  and  it  will  carry  out  the  search  function,  or  if  it  is 
determined  that  organic  resources  are  not  available,  the  system  will  then  wait  for  remote  search 
data  from  the  BMDS  that  will  be  passed  to  the  tracking  function.  From  this  point  on  in  both  this 
document  and  future  documents  this  type  of  track  data  transfer  will  be  called  Launch  on  Remote 
(LoR). 


Figure  C-3.  Search  Function 
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4.1.2  Detect 

The  Detect  function  is  shown  in  Figure  C-4.  The  Detect  function  is  started  when  search 
results  are  received  from  either  organic  or  remote  sensors.  The  results  from  the  search  function 
are  compared  against  the  current  file  of  existing  objects  and  the  system  determines  if  the  any  of 
the  attributes  are  either  new  or  have  changed.  If  changes  or  new  objects  are  noted,  the  location 
information  is  sent  to  the  Classify  function. 


Detect  Function 


Figure  C-4.  Detect  Function 
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4.1.3  Classify 

The  Classify  function  is  shown  in  Figure  C-5.  The  Classify  function  receives  object 
attributes  from  the  Detect  function  and  compares  them  against  algorithms  to  determine  if  they 
represent  ballistic  or  non-ballistic  objects.  Upon  determination  of  the  classification  of  the  objects, 
the  Classify  function  updates  the  object  attributes  including  the  identification  and  passes  the 
information  to  the  Track  function. 


Classify  Function 


Figure  C-5.  Classify  Function 
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4.1.4  Track 

The  Track  function  is  shown  in  Figure  C-6.  The  Track  function  receives  objects  from  the 
Classify  function  and  computes  the  object  trajectory.  After  determining  and  updating  the  track 
attributes,  the  track  file  is  updated  and  stored.  The  updated  tracking  data  is  sent  to  the 
Discrimination  function. 


The  Track  function  is  key  to  the  ability  of  the  ASBMD  System  and  is  independent  of  all 
other  functions  of  the  system.  The  Track  function  can  be  executed  using  remote  or  organic  track 
data  within  the  ASBMD  System.  Compilation  of  the  object  trajectory  will  be  used  to  help 
determine  the  ability  of  the  system  to  engage  the  object. 


Track  Function 


Figure  C-6.  Track  Function 
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4.1.5  Discriminate 

The  Discriminate  function  is  shown  in  Figure  C-7.  The  Discriminate  function  receives 
track  data  from  the  Track  function  and  evaluates  them  against  predetermined  discrimination 
algorithms.  The  output  of  the  evaluations  will  be  the  identification  of  the  number  of  lethal 
objects  in  the  current  track  gate.  If  the  output  of  the  evaluation  determines  that  there  are  more 
lethal  objects  than  previously  known,  the  Discrimination  function  will  notify  the  Track  function 
of  new  objects  to  be  tracked.  If  the  output  of  the  evaluation  determines  no  new  objects,  the 
Discrimination  function  will  update  the  attributes  of  the  existing  tracks  and  report  back  to  both 
the  Track  and  Engage  functions. 


Discrimination  Function 


Figure  C-7.  Discriminate  Function 
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4.1.6  Engage 

The  Engage  function  is  shown  in  Figure  C-8.  The  Engage  function  receives  track 
information  from  the  Discrimination  function  and,  upon  operator  initiation,  will  compute  and 
disseminate  the  fire  control  solution  for  the  selected  target.  After  operator  approval,  the  weapon 
will  be  deployed  and  the  Engage  function  will  compute  and  carry  out  the  guidance  and  kill 
assessment  portion  of  the  engagement.  The  Engage  function  is  also  responsible  for  creating  and 
communicating  the  current  status  of  the  engagement  to  the  larger  BMDS. 


Engage  Function 


Figure  C-8.  Engage  Function 
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5  CONCLUSION 


The  updated  System  Functional  flow  diagram  is  shown  in  Figure  C-9.  It  is  simplified,  but 
shows  the  key  flow  of  information  that  the  ASBMD  System  must  have  to  complete  the  intended 
mission. 


Figure  C-9.  System  Flow 
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ABBREVIATIONS  AND  ACRONYMS 


ASBM 

Anti-Ship  Ballistic  Missile 

ASBMD 

Anti-Ship  Ballistic  Missile  Defense 

dB 

Decibel(s) 

EO 

Electro-Optical 

ft 

Foot/Feet 

GBR-P 

Ground  Based  Radar  Prototype 

IR 

Infrared 

KM 

Kilometer(s) 

m 

Meter(s) 

RCS 

Radar  Cross  Section 

s 

Second(s) 

W 

Watt(s) 
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Probability  of  Detection  analysis  was  performed  for  of  each  of  the  four 
systems/elements  that  were  evaluated  to  fulfdl  the  search  and  detection  functions. 


Table  D-l.  Values  for  Calculation  of  Minimal  Detection  Range 
and  Probability  of  False  Alarm 


SPY-1 

SPY-3 

Cobra  Judy 

GRB-P 

P  peak 

Power  Transmitted  by  radar 

kw 

4000 

4500 

7000 

8000 

G 

Antenna  Power  Gain 

Unitless 

316.227 

330 

370 

375 

Ae 

Antenna  effective  area 

mA2 

20 

22.64 

25 

20 

<7 

Radar  Cross  Section  (RCS) 

mA2 

1 

1 

1 

1 

6000 

R 

Distance  from  radar  site  to  target 

km 

6000 

6000 

6000 

6000 

0.00 

Smin 

Minimal  Signal  Detection  or  Threshold 

0.003 

0.004 

0.004 

0.004 

0.002 

N 

Noise  Signal 

0.002 

0.002 

0.002 

0.002 

1 

Pf 

Probability  of  False  alarm 

0.188776089 

0.166952249 

0.121390393 

0.1263174 

Table  D-2.  Values  for  Probability  of  False  Alarm  vs.  Range 


SPY-1 

SPY-3 

Cobra  Judy 

GBR-P 

Pf 

Range 

Smin 

Pf 

Range 

Smin 

Pf 

Range 

Smin 

Pf 

Range 

Smin 

4.53E-05 

1000 

0.020006 

2.16548E-05 

1000 

0.021480569 

3.2E-06 

1000 

0.025305 

4.06E-06 

1000 

0.024827 

0.006727 

2000 

0.010003 

0.004653469 

2000 

0.010740285 

0.0017888 

2000 

0.012652 

0.002016 

2000 

0.012414 

0.035636 

3000 

0.006669 

0.027873054 

3000 

0.00716019 

0.0147356 

3000 

0.008435 

0.015956 

3000 

0.008276 

0.08202 

4000 

0.005002 

0.068216339 

4000 

0.005370142 

0.0422938 

4000 

0.006326 

0.044895 

4000 

0.006207 

0.13525 

5000 

0.004001 

0.116710715 

5000 

0.004296114 

0.0796198 

5000 

0.005061 

0.083513 

5000 

0.004965 

0.188776 

6000 

0.003334 

0.166952249 

6000 

0.003580095 

0.1213904 

6000 

0.004217 

0.126317 

6000 

0.004138 
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Figure  D-l.  Analysis  of  Probability  of  False  Alarm  vs.  Range 


Minimum  Detection  Signal  vs  Range 


Range  to  Target,  KM 


-SPY-1 

— ■— 

-  SPY-3 

— A— 

Cobra  Judy 

GBR-P 

Figure  D-2.  Analysis  of  Probability  of  Detection  vs.  Range 
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Equation  (D-l)  provides  the  calculation  of  affective  aperture  size: 


51020(0.3)2 


(D-l) 


Equation  (D-2)  provides  the  calculation  of  maximum  detection  range: 


PpeakG(jAe 

_  (4^)2  Smin  . 
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Table  D-3.  Calculation  of  Maximum  Detection  Range 
vs.  Radar  Cross  Section  (RCS) 


SPY  1 

SPY  3 

Cobra  Judy 

GBR-P 

Peak  Power 

4000000 

Watts 

Peak  Power 

4500000 

Watts 

Peak  Power 

7000000 

Watts 

Peak  Power 

8000000 

Watts 

Gain 

316227 

w/w 

Gain 

330000 

w/w 

Gain 

370000 

w/w 

Gain 

375000 

w/w 

Ae 

20 

mA2 

Ae 

22.64 

mA2 

Ae 

25 

mA2 

Ae 

20 

mA2 

Smin 

0.03 

w/w 

Smin 

0.005 

w/w 

Smin 

0.004 

w/w 

Smin 

0.005 

w/w 

Wavelength 

0.03 

m 

Wavelength 

0.03 

m 

Wavelength 

0.03 

m 

Wavelength 

0.03 

m 

RSC  dB 

RSC  W 

Range 

KM 

RSC  dB 

RSC  W 

Range 

KM 

RSC  dB 

RSC  W 

Range 

KM 

RSC  dB 

RSC  W 

Range 

KM 

1 

1.26 

1611 

1 

1.26 

2706 

1 

1.26 

3371 

1 

1.26 

3128 

2 

1.58 

1704 

2 

1.58 

2864 

2 

1.58 

3567 

2 

1.58 

3310 

4 

2.51 

1913 

4 

2.51 

3215 

4 

2.51 

4005 

4 

2.51 

3716 

6 

3.98 

2147 

6 

3.98 

3608 

6 

3.98 

4494 

6 

3.98 

4170 

8 

6.31 

2409 

8 

6.31 

4049 

8 

6.31 

5043 

8 

6.31 

4679 

10 

10 

2703 

10 

10 

4543 

10 

10 

5658 

10 

10 

5250 

Figure  D-3.  Maximum  Detection  Range  vs.  RCS 
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Table  D-4.  Values  for  Power-In  vs.  Range 


Ae  = 

1mA2 

P  = 

2000  w 

Range 

Pin 

0 

0 

200 

0.003979 

400 

0.000995 

600 

0.000442 

800 

0.000249 

1000 

0.000159 

2000 

3.98E-05 

3000 

1.77E-05 

4000 

9.95E-06 

5000 

6.37E-06 

6000 

4.42E-06 

7000 

3.25E-06 

8000 

2.49E-06 

9000 

1.96E-06 
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Figure  D-4.  Formula  for  Power-In  vs.  Range 


Power-In  vs  Range 


Figure  D-5.  Power-In  vs.  Range  for  EO/IR  Sensor 
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Table  D-5.  Power-In  vs.  Range  for  EO/IR  Sensor 


Target  Surface  Area  = 

3 

mA2 

Target 

Surface 

Area 

Range 

Pin 

Emissivity  = 

0.95 

0.5 

7035.407 

3.22E-06 

Temperature  = 

500 

K 

1 

9949.568 

1.61E-06 

Effective  Aperture  = 

1 

mA2 

1.5 

12185.68 

1.07E-06 

Frequency  Band  = 

2  -  6  um 

2 

14070.81 

8.04E-07 

Smin  “ 

0.0000006 

w 

2.5 

15731.65 

6.43E-07 

p  = 

2000 

w 

3 

17233.16 

5.36E-07 

3.5 

18613.94 

4.59E-07 

4 

19899.14 

4.02E-07 

4.5 

21106.22 

3.57E-07 

5 

22247.91 

3.22E-07 

5.5 

23333.8 

2.92E-07 
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Equation  (D-3)  provides  the  calculation  of  maximum  range  for  the  EO/IR  sensor: 


A, ax  = 


\sa{r -T:)A^AeF 


47rS. 


mm 


(D-3) 


Target  Size  &  Pin  VS  Detection  Range 


Figure  D-6.  Power  Target  Size  and  Power-In  vs.  Detection  Range 
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The  team  performed  operational  analysis  consisting  of  the  operational  range 
capabilities  of  the  platform.  This  is  the  range  that  the  host  platform  can  maneuver  away 
from  the  defended  asset  and  still  be  able  to  defend  it  if  fired  upon.  The  analysis  is  highly 
dependent  on  the  capabilities  of  the  interceptor  that  is  used  against  the  threat. 


Table  D-6.  Calculation  of  Maximum  Interceptor  Launch  Range 

vs.  Interceptor  Speed 


Max  Interceptor 
Launch  Range  (km) 

Interceptor  Speed 
(km/s) 

Z  range 

X/Y  Range 

480 

1.2 

50.00 

430.00 

640 

1.6 

50.00 

590.00 

640 

1.6 

50.00 

590.00 

800 

2 

50.00 

750.00 

960 

2.4 

50.00 

910.00 

1120 

2.8 

50.00 

1070.00 

1200 

3 

50.00 

1150.00 

1360 

3.4 

50.00 

1310.00 

1520 

3.8 

50.00 

1470.00 

1600 

4 

50.00 

1550.00 

Conversion  Units: 

ft 

meters 

miles 

km 

5280 

1655.172414 

1 

1.655172414 

160000 

50156.73981 

30.3030303 

50.15673981 

Assumptions:  Exoatmosphere  =  >  160K  ft  or  50  km 

Total  Target  Flight  Time  =  420  sec  Target  flight  time  to  re-entry  =  403  sec 

Organically  Tracked  3  sec  after  liftoff  Reaction  time  +  interceptor  flyout  400  sec 

Target  Speed  =  3  km/s  Constant  interceptor  speeds 
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Max  Operating  Range 


Figure  D-7.  Power  Maximum  Operating  Range  vs.  Interceptor  Speed 


Cross  Range  (km) 


*1.2  m/s 

*  2  m/s 

*  3  m/s 
*4  m/s 


Figure  D-8.  Maximum  Operational  Range  for  Host  Platform 
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The  team  performed  a  Data  Covariance  Analysis  to  determine  the  effects  of 
integrating  systems  that  output  filtered  data.  This  analysis  also  shows  the  effects  of 
filtered  data  on  a  system  that  is  designed  to  use  unfiltered  raw  data.  The  analysis  confirms 
that  trying  to  combine  multiple  sources  of  filtered  data  can  produce  an  outcome  that  is 
less  useful  than  if  the  system  uses  a  single  source  of  data. 


Table  D-7.  Calculation  of  Data  Covariance  for  Filtered  and  Non-Filtered  Sources 


Time 

Source 

1 

Track 

Points 

1 

Covariance 

Source 

2 

Track 

Points 

2 

Covariance 

2 

Filtered 

Filtered 

Track 

Points 

Filtered 

Covariance 

1 

10 

12 

2 

20 

22 

2 

15 

22 

7 

2 

14 

12 

2 

24 

22 

2 

19 

12 

7 

3 

18 

20 

2 

28 

30 

2 

23 

30 

7 

4 

21 

19 

2 

31 

29 

2 

26 

19 

7 

5 

23.5 

25 

1.5 

33.5 

35 

1.5 

28.5 

35 

6.5 

6 

25 

23 

2 

35 

33 

2 

30 

23 

7 

7 

26 

28 

2 

36 

38 

2 

31 

38 

7 

8 

27 

25 

2 

37 

35 

2 

32 

25 

7 

9 

28 

30 

2 

38 

40 

2 

33 

40 

7 

10 

29 

27 

2 

39 

37 

2 

34 

27 

7 
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Figure  D-9.  Maximum  Operational  Range  for  Host  Platform 


Figure  D-10.  Effects  of  Filtering  Data  on  Accuracy 
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ABBREVIATIONS  AND  ACRONYMS 


ASBM 

Anti-Ship  Ballistic  Missile 

ASBMD 

Anti-Ship  Ballistic  Missile  Defense 

BMD 

Ballistic  Missile  Defense 

CONOPS 

Concept  of  Operations 

dB 

Decibel(s) 

DRM 

Design  Reference  Mission 

DRMP 

Design  Reference  Mission  Profile 

EO 

Electro-Optic 

GBR-P 

Ground-Based  Radar-Prototype 

ICD 

Initial  Capabilities  Document 

IR 

Infrared 

km 

Kilometer(s) 

km/h 

Kilometer(s)  per  hour 

m 

Meter(s) 

MW 

Megawatt(s) 

Pd 

Probability  of  Detection 

PRF 

Pulse  Repetition  Frequency 

RCS 

Radar  Calculation  Sheets 
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Analysis  of  Alternatives  Artifacts 


Figure  E-l.  ASBMD  Analysis  of  Alternatives  Process 
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Table  E-l.  Key  Functional  Attributes 


Analysis 

Area 

Recommended  Attribute  Analysis 

Search  Rate  (Scan  Rate) 

Search 

Search  Volume  Capabilities 

Range 

Angular  Resolution 

Signal-to-Noise  Ratio 

Detection 

False  Alarm  Rate 

Probability  of  Detection  (Adjusting  Target  and  Environmental  Attributes) 

Radar  Range  Calculation  for  Maximum  Detection  Range 

PRF  and  Tracking  Errors 

Tracking 

Effective  Aperture  and  Resolution  Calculations 

Effects  of  Tracking  Ranges  Given  Tracking  and  Turning  Gate  Changes 

Transition-to-Track  Timeline  Analysis 

Intercept 

Variants 

General  Systems  Capability  Analysis 

Kill  Timeline  Analysis  by  Varying  Range 

Maximum  Effective  Ranges 
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Table  E-2.  System  Comparison  (Search/Detection) 


Function  Name  (Search/Detection) 

Options 

Performance  Parameters 

Requirements 

Pros  /  Cons 

Max 

Range/ 

Accuracy 

Max 

Power 

Ae 

(Effective 

Aperture 

Size) 

Smin 

SPY-1  B(D) 

*  1460  km 

3  MW 

20mA2 

-13dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than  750 
km  in  less  than  2  seconds,  when 
cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Mature,  proven  system  capability 

Con:  Shorter  maximum  range  limits  the 
maneuverability  options  of  the  Fleet 
Con:  Heavily  reliant  on  intelligence  data  to 
allow  for  resource  focusing 

SPY- 3 

**  2527  km 

4.5  MW 

23mA2 

-23dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than  750 
km  in  less  than  2  seconds,  when 
cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Greater  search  range  and  accuracy 
capabilities  than  the  SPY-1 

Pro:  Greater  peak  power  and  Ae  size 
allows  for  search  and  detection  of 
smaller  RCS 

Con:  Unproven  system  that  is  still  under 
development 

Con:  Power  usage  to  excite  radar  elements 
exceeds  that  of  current  ship 
capabilities 

Con:  Unable  to  uplink  with  current  weapon 
inventory 

Cobra  Judy 

**  2681  km 

7  MW 

26.4mA2 

-20dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than  750 
km  in  less  than  2  seconds,  when 
cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Greatly  Increases  search  and 
detection  ranges 

Pro:  Allows  greater  operational 
maneuverability 

Con:  Large  power  consumption 
requirements 

Con:  Unable  to  control  current  engagement 
weapons 

Con:  Too  large  to  fit  onto  current 
operational  naval  vessels 

GBR-P 

**  3297  km 

8  MW 

20.4mA2 

-23dB 

ASBMD  System  shall  be  capable 
of  searching  a  designated  search 
sector  of  not  less  than  30  degrees 
at  a  distance  of  not  less  than  750 
km  in  less  than  2  seconds,  when 
cued  by  either  off  board 
intelligence  or  the  onboard 
operator. 

Pro:  Increased  search  and  detection 
ranges 

Pro:  Increases  operational  capability  of 
fleet 

Con:  Power  consumption  is  too  large 

Con:  Weight  and  size  is  restrictive 

Con:  RCS  signature  much  too  large  for 
naval  vessel 

Con:  No  weapon  control  capability 

All  calculations  assume  30  degree  search  sector. 

*  Derived  from  Aegis  BMD  briefing. 

**  See  specific  Radar  Calculation  Sheets. 
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Table  E-3.  Function  Name  (Track) 


Function  Name  (Track) 

Options 

Performance  Parameters 

Requirements 

Pros  /  Cons 

Max 

Range/ 

Accuracy 

Max 

Power 

Ae 

(Effective 

Aperture 

Size) 

Smin 

SPY-1  B(D) 

*  1460  km 

3  MW 

20mA2 

-13dB 

ASBMD  System  shall  be 
capable  of  tracking  no  less 
than  2  simultaneous 
ballistic  missiles  at  a 
distance  of  not  less  than 

750  km. 

Pro:  Mature,  proven  system  capability 

Con:  Shorter  maximum  range  limits  the 
maneuverability  options  of  the  Fleet 

Con:  Heavily  reliant  on  intelligence  data  to 
allow  for  resource  focusing 

SPY- 3 

**  2527  km 

4.5  MW 

23mA2 

-23dB 

ASBMD  System  shall  be 
capable  of  tracking  no  less 
than  2  simultaneous 
ballistic  missiles  at  a 
distance  of  not  less  than 

750  km. 

Pro:  Greater  search  range  and  accuracy 
capabilities  than  the  SPY-1 

Pro:  Greater  peak  power  and  Ae  size  allows 
for  search  and  detection  of  smaller 

RCS 

Con:  Unproven  system  that  is  still  under 
development 

Con:  Power  usage  to  excite  radar  elements 
exceeds  that  of  current  ship  capabilities 
Con:  Unable  to  uplink  with  current  weapon 
inventory 

Cobra  Judy 

**  2681  km 

7  MW 

26.4mA2 

-20dB 

ASBMD  System  shall  be 
capable  of  tracking  no  less 
than  2  simultaneous 
ballistic  missiles  at  a 
distance  of  not  less  than 

750  km. 

Pro:  Greatly  Increases  search  and  detection 
ranges 

Pro:  Allows  greater  operational 
maneuverability 

Con:  Large  power  consumption  requirements 

Con:  Unable  to  control  current  engagement 
weapons 

Con:  Too  large  to  fit  onto  current  operational 
naval  vessels 

GBR-P 

**  3297  km 

8  MW 

20.4mA2 

-23dB 

ASBMD  System  shall  be 
capable  of  tracking  no  less 
than  2  simultaneous 
ballistic  missiles  at  a 
distance  of  not  less  than 

750  km. 

Pro:  Increased  search  and  detection  ranges 
Pro:  Increases  operational  capability  of  fleet 
Con:  Power  consumption  is  too  large 

Con:  Weight  and  size  is  restrictive 

Con:  RCS  signature  much  too  large  for  naval 
vessel 

Con:  No  weapon  control  capability 

EO/IR 

9.9  km 

N/A 

1mA2 

0.0000006  w 

ASBMD  System  shall  be 
capable  of  tracking  no  less 
than  2  simultaneous 
ballistic  missiles  at  a 
distance  of  not  less  than 

750  km. 

Pro:  Small  complex  system 

Pro:  Very  accurate  (<  2  m  error  at  maximum 
range) 

Con:  Unable  to  only  integrate  with  existing 
systems 

Con:  Maximum  usage  is  very  restrictive  for 
high  altitude  threat 

Con:  Requires  external  preloading 

commands  (no  automated  search 
capability) 

All  calculations  assume  30  degree  search  sector. 

*  Derived  from  Aegis  BMD  briefing. 

**  See  specific  Radar  Calculation  Sheets. 
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Table  E-4.  Function  Name  (Engage) 


Function  Name  (Engage) 

Options 

Performance  Parameters 

Requirements 

Pros  /  Cons 

Max 

Effective  Range 

Max  Closure  Speed 

SPY-T 

167  km 

3186  km/h 

ASBMD  System  shall  be  capable 
of  near  simultaneous  engagement 
of  no-less  than  2  ballistic  vehicles. 

Pro:  Currently  in  production 

Pro:  Flight  test  data  available  to  prove 
time  and  PK 

Con:  Max  range  limits  intercept  too  close  to 
or  within  atmosphere 

SPY- 3 

245  km 

4248  km/h 

ASBMD  System  shall  be  capable 
of  near  simultaneous  engagement 
of  no-less  than  2  ballistic  vehicles. 

Pro: 

Con: 

Rail  Gun 

400  km 

7430  km/h 

ASBMD  System  shall  be  capable 
of  near  simultaneous  engagement 
of  no-less  than  2  ballistic  vehicles. 

Pro:  Greater  range  than  conventional 
weapons 

Pro:  Greater  closure  speeds  increasing 
accuracy  due  to  less  time  for  target  to 
maneuver 

Pro:  Ten  shots  per  minute  allow  for 
multiple  shots  and  multiple 
engagements  in  short  time 

Con:  Inability  to  modify  flight  path,  very 
ineffective  against  fast  moving 
maneuvering  threats 

Con:  Heat  and  power  requirements  may 
exceed  capabilities  of  current  fleet 

Directed 

Energy 

System 

375  km 

N/A 

ASBMD  System  shall  be  capable 
of  near  simultaneous  engagement 
of  no-less  than  2  ballistic  vehicles. 

Pro:  Virtually  zero  delay  between  firing 

and  hitting  target  which  eliminates  the 
effects  of  moving  targets. 

Con:  Very  fragile  aiming  and  firing  systems 
Con:  Blooming  effects  cause  the 

breakdown  of  the  beam  at  distances 
greater  than  300  km 

*  Closure  speed  calculated  at  >  40  K  feet 

**  Rail  Gun  range  based  on  theoretical  values  derived  from  data  collected  during  2008  Navy  firings. 

185 


Appendix  E 


Figure  E-2.  Gross  System  Model 
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Figure  E-3.  Detailed  System  Model 
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Figure  E-4.  Functional  Sub-Model  Breakout  Example 
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ABBREVIATIONS  AND  ACRONYMS 


AoA 

Analysis  of  Alternatives 

ASBMD 

Anti-Ship  Ballistic  Missile  Defense 

CONOPS 

Concept  of  Operations 

DoD 

Department  of  Defense 

ICD 

Initial  Capabilities  Document 

IPR 

In-Process  Review 

KPP 

Key  Performance  Parameters 

MOE 

Measure  of  Effectiveness 

MOP 

Measure  of  Performance 

RMG 

Risk  Management  Guide 

SSP 

Strategic  Systems  Programs 

T&E 

Test  and  Evaluation 
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1  OVERVIEW 

Risk  is  defined  in  the  Risk  Management  Guide  (RMG)  for  Department  of  Defense 
(DoD)  Acquisition  (DoD,  2006,  August)  as  being  “a  measure  of  future  uncertainties  in 
achieving  program  performance,  goals,  and  objectives  within  defined  cost,  schedule,  and 
performance  constraints.”  Unfortunately,  both  technical  and  programmatic  risks  are  an 
inevitable  fact  of  system  development.  Identifying  and  planning  the  strategies  to  mitigate 
these  risks  before  they  become  issues  is  an  important  part  of  a  successful  systems 
engineering  process.  For  this  risk  management  process  to  be  effective,  it  must  be 
addressed  throughout  the  entire  system  development  process  by  the  technical  team  and 
program  management  team. 

The  DoD  RMG  provides  a  risk  management  process  model  that  can  be  used  (or 
tailored,  as  necessary)  to  manage  risk  throughout  the  system  acquisition  process.  This 
approach  to  managing  risk  was  chosen  by  the  Anti-Ship  Ballistic  Missile  Defense 
(ASBMD  team).  Figure  1-1  shows  the  key  activities  for  this  risk  management  process. 


Figure  F-l.  DoD  Risk  Management 
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2  RISK  IDENTIFICATION  AND  ANALYSIS 


The  first  step  in  the  DoD  risk  management  process  is  risk  identification.  The 
purpose  of  this  activity  is  to  identify  what  could  go  wrong  that  would  prevent  the  system 
development  from  succeeding.  The  next  activity  is  to  analyze  the  risks  that  have  been 
identified.  Risks  can  be  described  as  having  three  components: 


•  Root  cause,  which,  if  avoided,  would  prevent  an  issue  from  occurring 

•  Likelihood  that  this  root  cause  will  occur 

•  Consequence  of  this  occurrence 

Each  root  cause  must  be  assessed  as  to  the  likelihood  of  it  occurring  and  the 
consequence  to  the  program  development  if  it  was  to  occur.  The  DoD  RMG  categorizes 
three  types  of  risk  that  could  adversely  impact  the  success  of  a  system  acquisition: 
technical,  schedule,  and  cost.  The  DoD  RMG  also  provides  a  standard  format  for  a  matrix 
that  may  be  used  to  evaluate  and  report  the  results  of  the  risk  analysis  phase.  This  Risk 
Reporting  Matrix  is  shown  in  Figure  F-2.  The  level  of  risk  for  each  root  cause  is 
represented  as  low  (green  cells),  moderate  (yellow  cells),  or  high  (red  cells). 
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Figure  F-2.  Risk  Reporting  Matrix 
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Guidelines  are  provided  in  the  DoD  RMG  for  assigning  the  specific  level, 

1  through  5,  for  the  likelihood  and  consequence  of  each  root  cause.  The  level  definitions 
provided  in  the  DoD  RMG  were  evaluated  and  accepted  for  use  by  the  ASBMD  team 
when  analyzing  the  risks  for  the  system  architecture  development  effort.  Table  F-l  lists 
the  definitions  provided  in  the  DOD  RMG  that  correspond  to  each  level  of  the  likelihood 
and  probability  of  the  occurrence  of  a  risk’s  root  cause. 

Table  F-l.  Likelihood  Level  Criteria 


Level 

Likelihood 

Probability  of  Occurrence 

1 

Not  Likely 

~  10% 

2 

Low  Likelihood 

~  30% 

3 

Likely 

~  50% 

4 

Highly  Likely 

~  70% 

5 

Near  Certainty 

~  90% 

Table  F-2  lists  the  definitions  which  have  been  paraphrased  from  the  DoD  RMG 
for  use  by  the  ASBMD  team  for  each  level  of  consequence  if  a  risk’s  root  cause  were  to 
occur.  Level  definitions  are  provided  for  each  level  of  the  three  risk  categories. 
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Table  F-2.  Consequence  Level  Criteria 


Level 

Technical 

Schedule 

Cost 

i 

Minimal  or  no  consequence  to 
technical  performance 

Minimal  or  no  impact 

Minimal  or  no  impact 

2 

Minor  reduction  in  technical 
performance  or  supportability,  can  be 
tolerated  with  little  or  no  impact  on 
program 

Able  to  meet  key  dates 

Budget  increase  or  unit 
production  cost 
increase 
(<  1  %  of  budget) 

3 

Moderate  reduction  in  technical 
performance  or  supportability  with 
limited  impact  on  program  objectives 

Minor  schedule  slip; 
able  to  meet  key 
milestones  with  no 
schedule  float 

Budget  increase  or  unit 
production  cost 
increase 
(<  5%  of  budget) 

4 

Significant  degradation  in  technical 
performance  or  major  shortfall  in 
supportability;  may  jeopardize 
program  success 

Program  critical  path 
affected 

Budget  increase  or  unit 
production  cost  ' 

increase 

(<  1 0%  of  budget) 

5 

Severe  degradation  in  technical 
performance;  cannot  meet  KPP  or  key 
technical/supportability  threshold;  will 
jeopardize  program  success 

Cannot  meet  key 
program  milestones 

Exceeds  Acquisition 
Program  Baseline 
threshold 
(>  1 0%  of  budget) 
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3  RISK  MITIGATION  PLANNING  AND  TRACKING 

The  next  steps  in  the  risk  management  process  involve  mitigation  planning.  These 
activities  identify  and  evaluate  the  options  available  to  eliminate,  or  at  least  reduce,  the 
risks  that  could  jeopardize  the  success  of  the  system  architecture  development  effort. 
Successful  mitigation  plans  are  specific  as  to  what  needs  to  be  done,  when  it  needs  to  be 
done,  and  who  is  responsible  for  doing  it.  The  method  chosen  by  the  ASBMD  team  for 
documenting  risk  mitigation  plans  is  an  adaptation  of  the  template  created  by  the 
Strategic  Systems  Programs  (SSP),  SP23  Fire  Control  Section,  for  use  in  managing  the 
risks  associated  with  the  development  of  its  weapon  control  systems.  A  blank  copy  of  this 
template  is  shown  in  Figure  F-3. 


Risk: 

Description: 

Status: 

Context: 

Other 

Branches/O  rgs 
Effected: 

Assigned  to: 

Mitigation  Plan 

Step 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 

when  done 

Exit  Criteria 

Figure  F-3.  ASBMD  Risk  Mitigation  Plan  Template 

The  last  activity  of  the  risk  management  process  adopted  by  the  ASBMD  team  is 
risk  tracking.  The  ASBMD  team  completed  regular  reviews  of  the  identified  risks  and 
their  associated  mitigation  plans  as  part  of  a  regular  weekly  team  meeting. 

The  most  important  aspect  of  this,  or  any,  risk  management  process  is  that  it  is 
continuous  and  needs  to  be  revisited,  iteratively,  until  the  system  development  has  been 
successfully  completed.  This  aspect  of  risk  management  was  also  adopted  by  the 
ASBMD  team  and  regular  reviews  of  risk  included  the  identification  of  any 
new/emerging  risk  root  causes.  As  new  risks  were  identified,  mitigation  plans  were 
created  and  regularly  reviewed. 
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4  ASBMD  PROJECT  AND  SYSTEM  RISKS 

The  ASBMD  team  had  two  primary  areas  of  risk  that  were  identified  and  tracked. 
One  area  was  project  management-related  and  encompassed  the  risks  associated  with 
successfully  completing  this  Capstone  Project.  The  risk  reporting  matrix  for  project 
management  risks  is  shown  in  Figure  F-4.  Table  F-3  summarizes  these  project 
management  risks  and  includes  an  identifier  used  to  track  the  risk,  a  description  of  the 
root  cause,  and  the  status  of  the  risk  at  the  time  of  the  Capstone  In-Process  Review 
(IPR)  #2. 
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Figure  F-4.  ASBMD  Project  Management  Risk  Matrix  (as  of  IPR  #2) 
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Table  F-3.  ASBMD  Project  Management  Risk  Summary  (as  of  IPR  #2) 


Risk  ID 

Description 

Status 

PI 

Team  will  not  be  able  to  generate  a  list  of  viable  alternatives  in  a  timely 
manner. 

Closed 

P2 

The  team  will  not  decide  on  a  list  of  Key  Performance  Parameters 
(KPPs)  in  a  timely  manner.) 

Closed 

P3 

Modeling  and  simulation  tools  will  not  be  developed  in  time  for  use  in 
the  Analysis  of  Alternatives  (AoA). 

Improving 

P4 

Final  project  report  will  not  be  completed  on  time. 

No  change 

P5 

Team  will  not  be  able  to  identify  viable  candidate  systems  to  support 
the  AoA  process.) 

Closed 

The  second  area  of  risk  was  related  directly  with  the  technical  challenges  of 
developing  the  ASBMD  system  itself.  The  risk  reporting  matrix  for  system  engineering 
risks  at  the  time  of  the  IPR  #2  is  shown  in  Figure  F-5.  Table  F-4  provides  a  summary  of 
these  systems  engineering  risks. 
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Figure  F-5.  ASBMD  System  Engineering  Risk  Matrix  (as  of  IPR  #2) 
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Table  F-4.  ASBMD  System  Engineering  Risk  Summary  (as  of  IPR  #2) 


Risk  ID 

Description 

Status 

SI 

The  chosen  solution  is  not  able  to  be  integrated  with  existing 
systems. 

Improving 

S2 

The  test  agency  will  need  to  acquire  a  functionally 
representative  threat  target  to  test  the  proposed  ASBMD 
system. 

No  change 

S3 

Necessary  resources  must  be  planned  and  allocated  to  backfit 
the  system  solution(s)  into  the  Fleet. 

No  change 

Risk  mitigation  plans  were  developed  for  each  of  these  risk  root  causes  and  were 
tracked  by  the  ASBMD  team.  Tables  F-5  through  F-12  show  the  mitigation  plan  for  each 
of  these  risks  at  the  time  of  the  second  IPR  briefing.  Since  the  second  IPR,  the  ASBMD 
team  has  continued  its  work  and  its  commitment  to  risk  management.  All  risks  have  been 
mitigated  to  ensure  the  successful  completion  of  our  Capstone  Project. 
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Table  F-5.  Risk  Mitigation  Plan  for  Risk  PI 


Risk: 

PI :  The  team  will  not  be  able  to  generate 
a  list  of  viable  alternatives  to  counter  the 
threat  in  a  timely  manner,  so  the  analysis 
of  alternatives  will  be  delayed. 

Description: 

Research  still  needs  to  be  done  by  the 
team  members  to  narrow  the  scope  on 
what  the  threat  is  and  what  is  needed  to 
combat  that  threat.  This  will  be  a 
challenge  with  individual  work  schedules, 
travel  schedules,  and  personal 
commitments. 

Status: 

Closed 

Context: 

Scope,  schedule,  and  resource  planning 

Other 

Branches/Orgs 

Effected: 

Stakeholders 

Assigned  to: 

Team  1 

Mitigation  Plan 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1 )  Discuss  research  progress  at  weekly 
team  meetings. 

1 -May-09 

15-Aug-09 

Y 

2)  Plan  milestones  and  track  progress  on 
the  team  schedule  for  the  definition  of 
alternatives  to  consider. 

1 -May-09 

15-Aug-09 

Y 

3)  Perform  research  to  define  the  scope 
of  the  threat  we  are  addressing. 

15-May-09 

30-Jun-09 

Y 

4)  Perform  research  to  investigate  any 
existing  systems  that  may  be  used  for 
the  ASBMD  architecture. 

31  -Jul-09 

15-Aug-09 

G 

5)  Generate  list  of  alternatives  for  further 
analysis. 

31-Jul-09 

15-Sep-09 

Close  Risk 

Exit  Criteria 

Team  consensus  on  what  the  ASBMD 
system  needs  to  do  and  a  list  of  viable 
alternatives  that  could  be  used  to 
implement  it. 
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Table  F-6.  Risk  Mitigation  Plan  for  Risk  P2 


Risk: 

P2:  The  team  will  not  decide  on  a  list  of 
KPPs  in  a  timely  manner,  so  analysis  of 
alternatives  will  be  delayed. 

Description: 

There  will  be  many  choices  for  MOEs 
and  MOPs.  The  team  will  need  to  select 
only  a  few  for  use  as  KPPs  and  come  to 
an  agreement  on  what  these  should  be. 
Plus,  there  is  always  the  challenge  of 
individual  work  schedules,  travel 
schedules,  and  personal  commitments. 

Status: 

Closed 

Context: 

Scope,  schedule  and  resource  planning 

Other 

Branches/Orgs 

Effected: 

Stakeholders 

Assigned  to: 

Team  1 

Mitigation  Plan 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1 )  Designate  a  lead  for  the  KPP 
selection.  The  lead  will  keep  the  effort 
on  track  and  direct  work  on  the  task. 

1 -May-09 

1 -May-09 

Lead  is 
Mike 
Roberts 

Y 

2)  Plan  milestones  and  track  progress  on 
the  team  schedule  associated  with 
MOE/MOP  evaluation  and  KPP 
selection. 

1 -Aug-09 

15-Aug-09 

Y 

3)  Decide  what  MOEs/MOPs  are  desired 
and  investigate  what  data  is  available. 

15-Aug-09 

15-Aug-09 

G 

4)  Generate  list  of  KPPs  to  use  for  the 
analysis  of  alternatives. 

31 -Aug-09 

30-Aug-09 

Close  Risk 

Exit  Criteria 

Team  consensus  on  the  ASBMD  system 
KPPs. 
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Table  F-7.  Risk  Mitigation  Plan  for  Risk  P3 


Risk: 

P3:  Modeling  and  simulation  tools  will 
not  be  developed  in  time  for  their  use  in 
the  analysis  of  alternatives. 

Description: 

Because  of  competing  individual  work 
schedules,  travel  schedules,  and 
personal  commitments,  the 
development  of  tools  to  analyze 
alternatives  is  delayed.  This  also  might 
occur  if  other  project  risks  are  not 
properly  or  fully  mitigated. 

Status: 

Closed 

Context: 

Schedule  and  resource  planning 

Other 

Branches/Orgs 

Effected: 

Stakeholders 

Assigned  to: 

Team  1 

Mitigation  Plan 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1)  Designate  a  lead  for  the  model  and 
simulation  development.  The  lead 
will  keep  the  effort  on  track  and 
direct  work  on  the  task. 

1 -May-09 

22-May-09 

Y 

2)  Plan  milestones  and  track  progress 
on  the  team  schedule  associated 
with  tool  development. 

1-Jun-09 

31 -Aug-09 

Y 

2(a)  Perform  modeling  proficiency 
demonstration. 

15-Jun-09 

12-Jun-09 

G 

3)  Come  to  an  agreement  on  what  tools 
are  needed. 

15-Jul-09 

1 -Aug-09 

G 

4)  Generate  needed  tools. 

1 5-Aug-09 

31 -Aug-09 

Close  Risk 

Note:  Modeling  Overview  was  delivered 
to  advisors  on  31 -Aug-09. 

Exit  Criteria 

Tools  are  available  for  use. 
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Table  F-8.  Risk  Mitigation  Plan  for  Risk  P4 


Risk: 

P4:  Final  project  report  will  not  be 
completed  on  time. 

Description: 

Because  of  competing  individual  work 
schedules,  travel  schedules,  and 
personal  commitments,  the  writing  of 
the  project  report  and  presentation  is 
delayed.  This  also  might  occur  if  other 
project  risks  are  not  properly  or  fully 
mitigated.  A  lead  for  this  task  has 
already  been  chosen:  Jeannie 

Hobgood. 

Status: 

Improving 

Context: 

Schedule  and  resource  planning 

Other 

Branches/Orgs 

Effected: 

None 

Assigned  to: 

Team  1 

Mitigation  Plan 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1 )  Plan  milestones  and  track  progress 
on  the  team  schedule  for  the  project 
report  and  presentation. 

1 -May-09 

on-going 

G 

2)  Start  the  project  report  with 

information  for  chapters  1  and  II  and 
the  PMP  appendix  at  the  end  of  the 
first  quarter  (Spring  2009).  Also  start 
the  final  project  presentation  slides. 

30-Jun-09 

6-Jul-09 

Released  draft 
of  Chap.  1  and 
have 

CONOPS  and 
ICD 

documents  to 
use  for  other 
chapters 

G 

3)  Update  the  project  report  and 
presentation  with  information 
available  at  the  end  of  the  second 
quarter  (Summer  2009). 

1  -Oct-09 

23-Oct-09 

Chap  3 
released  for 
review  and 

IPR  #2 

G 

4)  Complete  chapter  4  and  remaining 
sections  (appendices,  abstract, 
executive  summary,  etc).  Assemble 
and  release  for  final  team  review. 

20-Nov- 

09 

G 

5)  Complete  final  report  and  submit  for 
department  review. 

30-Nov- 

09 

Close  Risk 

Exit  Criteria 

Correctly  formatted  report  is  submitted 
to  Systems  Engineering  department. 
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Table  F-9.  Risk  Mitigation  Plan  for  Risk  P5 


Risk: 

P5:  The  team  will  not  be  able  to  find 
feasible  solutions  to  meet  the  stated 
need. 

Description: 

Although  exhaustive  research  and 
analysis  has  been  done,  the  team 
cannot  recommend  a  solution  that  will 
resolve  the  problem  statement. 

Status: 

Closed 

Context: 

Technical 

Other 

Branches/Orgs 

Effected: 

Stakeholders,  Advisors 

Assigned  to: 

Team  1 

Mitigation  Plan 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1 )  Discuss  research  and  analysis 
findings  at  team  meetings. 

15-Jul-09 

15-Jul-09 

G 

2)  Discuss  alternatives  and  brainstorm 
ideas. 

1 -Aug-09 

1  -Aug-09 

G 

3)  Generate  table  of  alternative 
architectures  for  each  functional 

area. 

15-Sep-09 

15-Sep-09 

Close  Risk 

Exit  Criteria 
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Table  F-10.  Risk  Mitigation  Plan  for  Risk  SI 


Risk: 

SI:  The  chosen  solution  is  not  able  to 
be  integrated  with  existing  systems. 

Description: 

Although  exhaustive  research  and 
analysis  has  been  done,  the  team 
cannot  recommend  a  solution  that  will 
work  with  existing  systems. 

Status: 

Improving 

Context: 

Technical 

Other 

Branches/Orgs 

Effected: 

Stakeholders,  Advisors 

Assigned  to: 

Team  1 

Mitigation  Plan 

Steps 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1 )  Discuss  research  and  analysis 
findings  at  team  meetings. 

15-Jul-09 

15-Jul-09 

Y 

2)  Discuss  alternatives  and  brainstorm 
ideas. 

1 5-Aug-09 

15-Aug-09 

Y 

3)  Primary  selection  criteria  for 

alternatives  include  interoperability. 

1 -Sep-09 

1 -Sep-09 

G 

4)  Chosen  architecture  for  system  of 
systems  supports  interoperability. 

15-Nov-09 

Close  Risk 

Exit  Criteria 
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Table  F-ll.  Risk  Mitigation  Plan  for  Risk  S2 


Risk: 

S2:  Development  of  Test  Threat 
Simulator 

Description: 

The  aim  of  this  project  is  to  eliminate  a 
non-traditional  threat  that  we  currently 
have  no  technological  equivalent  of. 

The  Test  and  Evaluation  (T&E)  Agency 
is  going  to  have  to  develop  an 
operationally  representative  threat  to 
test  the  capability  of  any  proposed 
system. 

Status: 

Improving 

Context: 

Technical 

Other 

Branches/Orgs 

Effected: 

T&E  Agency  &  Program  Office 

Assigned  to: 

T&E  Agency 

Mitigation  Plan 

Step 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1)  Make  T&E  and  Program  Office 
group  aware  of  risk. 

15-Jul-09 

20-Jul-09 

G 

2)  Monitor  T&E  plan  development 
(include  coverage  in  final  report). 

15-Nov-09 

Close  Risk 

Exit  Criteria 
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Table  F-12.  Risk  Mitigation  Plan  for  Risk  S3 


Risk: 

S3:  Outfitting  the  Current  DoD  assets 
with  Solution 

Description: 

The  ability  to  "backfit"  current 
hardware  with  a  solution  is  historically 
a  challenge.  Identifying  resources 
needed  and  implementing  a  plan  are 
critical. 

Status: 

Improving 

Context: 

Financial,  Programmatic 

Other 

Branches/Orgs 

Effected: 

Program  Office,  Resource  Sponsor 

Assigned  to: 

Program  Office 

Mitigation  Plan 

Step 

Planned 

Completion 

Actual 

Completion 

Status 

Risk  State 
when  done 

1)  Identify  required  resources  for 
backfit. 

1 -Nov-09 

4-Nov-09 

Y 

2)  Consider  costs  for  those  resources. 

15-Nov-09 

19-Nov-09 

G 

3)  Address  results  in  final  report. 

20-Nov-09 

Close  Risk 

Exit  Criteria 
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